Если стоит вопрос обоснования решения, то значит скорее всего оно не единственное. А это значит, что ваше утверждение насчёт никак уже неверно

Да, это очень просто реализовать. Но технология из 90х, когда не было возможности прокинуть событие другими способами

Это я пытался "тонко обьехать" другие траспорты для "событий"

Не пуш-пулом единым.. и не северпушем, ога

По запросу нужно проверить есть ли обновления для клиента и если есть, то их отослать. Обновления могут быть до 1 килобайта

А как проверяется наличие обновлений? БД? Redis? Как-то еще?

Редис.

А какая нагрузка планируется? И что на сервере все-таки?

Предел хочется понять такого подхода. На сколько он скейлится.

Сильно зависит от серверного движка.
Если там тредовая модель, то больше тысячи одновременных запросов не переварить, так что любая задержка на выполнении запроса приведет к падению производительности (причем важно не среднее, а число самых долгих запросов).
Если современный асинхронный фреймворк, то нужно тесты сделать.

Простой пример, можно сделать корутины с котлина (типа ассинхронный фреймворк), когда вы держите виртуальные треды, асинхронно. Но по факту под ними открываются и закрываются реальные треды в jvm, вот вам и тредовая модель под, но сверху накрутили виртуальные потоки с фреймворком. Дело то не втредах тут и корутинах. Тут спасет балансировщик, разделение БД на типы данных, кеши и индексы. Кейс Баду читал, и да там котлин и корутины, а работают с БД (частые, нет, чтение, запись, критичные данные, нет) кешем, индексами.

Угу. Я потому и спрашивал про серверный движок. У меня как раз на кторе все.

Если мы говорим про действиетельно необходимость hl и и почти мгновенного ответа. В энтерпрайзе некоторые считают что пользователь может подождать. Не столь конкурентна среда в этом отношении.

Привет.
Небольшой оффтоп вопрос.
Может кто-нибудь сказать, какое у вас соотношение разработчиков-тестировщиков и системных администраторов?

Т.е. команды разработки и сервисной команды админов.

У нас 1:10 примерно, в принципе на предыдущих местах работы было примерно также, от 1:20 до 1:10

Разное, ведь количество разрабов больше зависит от количества функционала, а админов - от количества систем в проде.

1 к 4рем примерно, тестеров - нуль.

Необычное соотношение.
У вас какого характера разработка? Много инфраструктуры?

Опять же, класс критичности приложений влияет - 24/7 business critical требует в ~3 раза больше админов, чем 8/5 office productivity