Сколько машин достаточно для сервиса с небольшой нагрузкой
Что проверяют
Считаете ли вы ёмкость или называете число наугад. И понимаете ли главное: при небольшой нагрузке количество машин определяется требованиями к доступности, а не производительностью, потому что один экземпляр на Go обычно закрывает такую нагрузку с запасом.
Как отвечать
Сначала уточните вводные: сколько запросов в секунду в пике, какой SLO по задержке, сколько процессорного времени стоит один запрос, есть ли состояние, куда сервис ходит дальше. Без этого ответ бессмысленен, и интервьюер как раз ждёт этих вопросов.
Дальше считайте вслух. По закону Литтла нужная конкурентность равна пропускной способности, умноженной на время ответа. По процессору: двести запросов в секунду по пять миллисекунд процессорного времени это одно ядро, то есть по ёмкости хватает одной небольшой машины.
Вывод формулируйте так: по ёмкости достаточно одной, ставить нужно минимум две в разных зонах доступности. Одна машина означает простой при каждом выкате, при перезагрузке узла и при любой аварии у провайдера. Планировать стоит на отказ одного экземпляра, целясь в половину утилизации, чтобы пик и деплой не совпали с потолком.
Go-специфика, которую ждут: горутины дёшевы, и приложение редко становится узким местом, упирается база или внешний вызов. В контейнере с лимитом CPU надо согласовать GOMAXPROCS с лимитом, иначе рантайм видит все ядра узла и получает троттлинг, а GOMEMLIMIT помогает сборщику мусора не упереться в предел памяти.
Где спотыкаются
Называют число сразу, без единого уточняющего вопроса. Ответ «две или три» без вводных не отличить от угадывания, даже когда он случайно верен.
Считают только пропускную способность и приходят к одной машине. Сервис должен отвечать и во время выката, и во время обновления узла, а одна машина этого не позволяет.
Масштабируют приложение, упираясь в базу. Добавили экземпляры, каждый со своим пулом соединений, база получила кратно больше подключений, и после масштабирования стало хуже, чем было.