Если приложение небольшое, то стоит разбивать нго не по формам, а по функционалу. Да и «монолит» можно сделать модульным. А при нагрузках эти модули выносить на отдельные инстансы. Ну и микросервисы, если и делать, то максимально независимыми друг от друга. Идея не передавать данные из одного в другой, а обогащать и агрегировать эти данные.
И емли хорошо архитектуру не продумать заранее, то получите головную боль большую, чем при монолите.
Делайте слабо связанный проект, используйте шины сообщений, распределенные базы данных, отделяйте бекэнды от фронта. Идите от данных. Уходите от REST. В сторону graphql или grpc или подобного.
ol1vka, а вы не бойтесь, мы не кусаемся :-) я на полном серьезе! ищите группы (телеграм моден нынче очень!) программистов в своем городе-странн. Среди них наверняка есть и желаемой возрастной категории.
fleksss_pod_papicha, ну, что же, самый примитивный, и самый затратный для сервера по ресурсам способ! Но и самый простой для клиента.
Представим, что у нас 1000 онлайн клиентов - только этот пинг-понг обойдется нам почти в 6 запросов в секунду (rps) совершенно бесполезной нагрузки на сервер. А при 10000 клиентов сервер и прилечь может- 60 rps не шутка, да скорее всего и приляжет....
Виктор Таран, э.. ну.. inode - это не про ядро, а про файловую систему все же, и ее организацию... А вот - файловые дескрипторы, да есть ограничение, но на 64-х битных ядрах, можно считать - нет...
Ну а то, что зарезать можно и лимиты поставить - это же хорошо, но опять же - не к ядру линукса вопрос, а к хостеру. Берите виртуалочку - и в путь!
