Имею в виду, например, открытые соединения, состояния вебсокетов, какие-нибудь интерактивные вещи, которые в раме лежат

и как сейчас решают это?

Примерно такая ситуация и произошла там, где я начала сейчас работать. Толпа джунов из дешёвой страны, пхп, ВордПресс, крест, гроб.
Переписываем на Эликсир.

Какие-нибудь алгоритмы синхронизации данных. Это могут быть и неконфликтные структуры данных, это могут быть консенсусы, это могут быть мастер/слейв репликации и так далее

Расист! Расист!!!!

Для всего этого у каждого контейнера во время работы есть какое-то состояние, поэтому просто добавить/убрать контейнер не получится. Вообще, этот хвалёный автоскейлинг на моём опыте редко помогал как-то реально увеличить пропускную способность

Точнее, она увеличивалась, но пока всё это происходит, нагрузка уже успевает упасть
Вам кому-нибудь когда-нибудь автоскейлинг помогал?

при чем тут расизм? это бдсм терминология

как джс-макака отвечу что наверное Go

У вилки три зуба! Типа испытательный срок и реальный срок? Во всех смыслах.

Вроде бы в го конкурентный сборщик мусора настроенный на low latency, и подвиснуть надолго он может только если этот мусор ну очень старательно плодить.

ну тут как и с любой другой технологией, нужно уметь ее готовить

Так можно сказать про любой сборщик мусора. В голанге, например, всё ещё нет защиты от неаккуратного использования shared memory (даже unsafe-а растового нет). Поэтому сборка мусора тут STW и довольно жирная. То, что она low latency это какое-то странно утверждение. Зная алгоритм сборки мусора в голанге, могу сказать что это точно не самый эффективный и быстрый алгоритм сборки мусора: какие-нибудь jvm и .net в этом плане сильно эффективнее

Так, поделишься кулинартным секретом?

лично у меня такого опыта нет, но есть у коллег

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

главное правильно подобрать лимиты, чтобы это не работало так топорно, как ты описал

той же командой?

Ну лимиты это понятно, но инициализация у сервисов это очень мутная и долгая тема. Если запросы раскидываются сложнее чем по хэшрингу, будет не так просто что-то добавить или убрать, нужен будет консенус или регистрация сервиса где-нибудь. А на это уже уходит время

Особенно с консенсусом беда, потому что под нагрузкой в каком-нибудь голанге (где у рутин нет приоритетов (нет же?)) это будет сложно провернуть

На практике, в Go же оптимизированный GC, заостренный на минимальные прерывания, так что вопрос - какое количество реальных сервисов на Go - с зависшеми рутинами встречаются, как и с тормозящим GC.

Т.е. Не смотря на теоретическую возможность и скорее всего не частые случаи (предположение) - вопрос, насколько эта проблема реально часто встречается.

К примеру, у меня мой друг работает на Go - так он каждый раз с удивлением на меня смотрит, когда я ему говорю про stop the world GC или про зависшую гоурутину. Потому что на их высоко-нагруженном сервисе - такое за много лет ни разу не встречалось.