Потом, сильно решает штат программистов, количество серверов, которые можно купить (если они железные). Опять же возможность написать это на облаке

А самое главное, это вероятность изменения задания со временем

В двух словах, если есть вероятность что проект придётся поддерживать разным людям, то go. Если проект будет стоять огромным монолитом на одной машине и никогда не меняться, то можно использовать плюсы. Если проект раскидан по большому количеству машин со сложной логической архитектурой и высокой надёжностью в тз, то elixir. Если cloudnative, то java

Можно использовать rust, но на свой страх и риск, потому что технология совсем новая и программистов на расте днём с огнём...

Да это все мне не надо разъяснять, ты скажи сколько рпс на эликсире выжимаешь

Пофиг на чем , хоть на хелло ворлде

А сколько машин?

Ну вот допустим 200к, на скольких бюджетных (более менее )разъедется?

Про программеров на расте вообще никого живых не видел, подозреваю что их ещё меньше чем эликсирщиков.

Ну я ж вчера писал ) у меня получилось 65Krps вчера на мак про

Да точно, я помню

Если plug/cowboy, то нужно 3-4. Это самое популярное и надёжное решение
Если чистый cowboy, то на машинку поменьше
Если кастомный сервер написать и обернуть HTTP парсер во что-нибудь на сях (советую picohttp), то я думаю хватит и одной

Касательно базы сзади, я везде писал с расчётом на мастер-slave кластер какой-нибудь посгтри

Да ок, а с базой что посоветуешь? Будет ок 40к writes

База под задачу

Не знаю что сказать

Ок, спасиб. Опередил))

Кто-то использовал Umbrella-приложения вместе с Ecto? Возникла потребность в отдельном приложении, которое будет в себе хранить какие-то данные, но будет ссылаться на Ecto Schemas из другого приложения. Свои Ecto Schemas будут ссылаться на ту же базу данных, но под другой Postgres Schema.

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

Один репо на все и всё нормально

вообще лучше архитектурно сделать так, что есть аппка которая отвечает за схемы и модели которые в БД, а отсальные аппки ими пользуются