Это такая же соль. Только кто додумался ещё раз посолить.

Есть сванская соль, есть гималайская, а есть йодированная

гималайская вкусная, рекомендую)

Есть люди, что и сахар добавляют, а есть, даже смешивают соль, сахар и перец, но у них это ни кто не берет

Это уже китайская кухня. Люблю китайскую кухню.

@tshemsedinov ,  какую бд изучать и использовать PostgreSQL или Postgres PRO Standart? Какие у них отличия? И какой адаптер для ноды?

Postgres PRO Standart - это нестандартная сборка комнапии Postgres professional, ставьте обычную https://www.postgresql.org/download/ для ноды у меня есть лекции, и примеры кода, см их

Спасибо))))

Проблемы монолитов в эпоху serverless...)

В этом то может и быть проблема , что все уповая на «облака» забудут как работать «руками» ))))

серверлес не для принятия нагрузки, это же 1 процесс под 1 запрос, не node way

В опроснике нет варианта "автоматический балансировщик в облаке". Имхо, если деплой уже в облаке то это самый очевидно верный вариант

Это ыариант - все само как-то работает

до "эпохи serverless" еще как минимум снижение ценника раз в 10, и много лет разработки инструментария для разработки в этом самом serverless, а пока это очень дорогой узкоспециализированный и жесточайший вендор лок. В общем если у вас есть возможность избежать serverless - стоит избигать всеми возможными способами

От этого пропадают симптомы и проблема перестает быть явной, но это не избавляет от оптимизации принятия нагрузки в приложении. Абстрактеые 1000 запросов в секунду, которые вполне способен обработать сервер, будут быстрее обрабатываться с параллелизмом 100 и очередью 900, чем все сразу.

согласен, "эпоха serverless" громко сказано...
все зависит от специфики продукта. у нас вот лямбда очень даже зарешала

Подумал над вашим утверждением и могу с ним согласится только от части: во-первых, если сервер для обработки запроса делает запросы в базу или внешние сервисы то 1000 параллельных почти наверняка будут обработаны быстрее чем очередями по 100, так как пиковая нагрузка в момент поступления запросов сменится простоем после первого-же асинхронного вызова. Как результат, по 100 может обрабатыватся до 10 раз дольше чем все 1000 сразу. Во-вторых, libuv уже является асинхронной очередью в пределах одного процесса, так что любой дополнетильный механима (в пределах одного процесса) скорее всего только ухудшит производительность сревера. В-третьих использование паралеллизма для обработки запросов сервером это как раз то как явно рекомендовали НЕ делать: на вскидку вот хорошая статья https://blog.insiderattack.net/deep-dive-into-worker-threads-in-node-js-e75e10546b11 где объясняется (в конце) почему так делать не нужно, но если нужно я могу найти выступление Anna Henningsen где она говорила о том как они боялись вводить worker threads так как переживали что люди начнут их использовать для параллельной обработки запросов, а это как раз то что делать с ними не нужно

Мораль лонгрида: варианты ответов опроса это о том как решать проблему того что не справляется сервер, и ее решать такими способами скорее не нужно. Если мы имеем ресурсное голодание, то есть сервер справляется, а не справляется сервис, то проблему нужно решать с сервисом, а не с сервером. Если это база - вы лучше кого угодно в чате знаете что делать 🙂 Если это внешний сервис - например, баунсить к нему запросы. Попытки-же решить проблему с сервисами на уровне сервиса убъют производительность всего приложения

* сори, не та статья. Сейчас найду другой пруф