Почему нельзя направить весь трафик на одну машину

Что проверяют

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

Как отвечать

Сразу разделите две причины. Пропускная способность это только половина: одна машина упирается в ядра, в память, в лимит файловых дескрипторов, в таблицу conntrack и в диапазон эфемерных портов. Но честный ответ в том, что многие сервисы на Go одну машину и не загружают, а в нескольких экземплярах их держат всё равно.

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

Дальше покажите, что знаете цену вопроса. Горизонтально расходится только сервис без локального состояния. Кэш в памяти процесса, счётчики ограничителя запросов, залипающие сессии, планировщик внутри бинаря: всё это на двух экземплярах ведёт себя по-разному. Состояние переезжает в общее хранилище, а фоновые задачи получают выбор лидера или отдельный запуск.

Где спотыкаются

Отвечают одной фразой про единую точку отказа и замолкают. Интервьюер ждёт продолжения: что именно сломается в вашем коде при двух экземплярах и куда переедет состояние.

Второе: обещают линейный рост от добавления машин. Приложение масштабируется, база нет, и после третьего экземпляра узким местом становится пул соединений к ней, а не процессор сервиса.

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