Был ли сервис масштабируемым и поддерживал запуск нескольких экземпляров

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

Вопрос про ваш реальный проект: понимаете ли вы, что мешает запустить сервис в нескольких копиях. Ответ «да, он крутился в Kubernetes» не засчитывается, важно, где у сервиса лежит состояние. Следом спрашивают, что происходило с фоновыми задачами и базой при добавлении реплик.

Как отвечать

Опирайтесь на свой сервис и пройдите по источникам состояния:

• сессии: если они в памяти, нужны sticky sessions на балансировщике, Spring Session с Redis или stateless-аутентификация на JWT;
• кэш: локальный Caffeine на каждой реплике расходится после изменений, общие данные держат в Redis или ставят короткий TTL;
• фоновые задачи: @Scheduled запускается на каждой копии. Дубли убирают через ShedLock, кластерный Quartz или выносом задач в отдельный процесс;
• очереди: в Kafka параллелизм ограничен числом партиций, лишние консьюмеры простаивают. Обработчики должны быть идемпотентными;
• база: реплики умножают пул соединений. У HikariCP по умолчанию 10 соединений, у PostgreSQL max_connections = 100, и десяток подов упирается в лимит раньше, чем в CPU;
• миграции: Flyway и Liquibase берут блокировку, одновременный старт реплик безопасен, но долгая миграция задержит все поды;
• жизненный цикл: server.shutdown=graceful, readiness и liveness пробы через Actuator, чтобы балансировщик не слал запросы на стартующий или гаснущий под.

Закончите тем, как масштабировались: HPA по CPU или по длине очереди, какие были пределы и где оказалось узкое место.

Если сервис жил в одном экземпляре, скажите честно и разберите, что сломалось бы при второй копии и как бы вы это чинили. Такой разбор ценится не меньше истории успеха. Цифры приводите только свои.

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

Рассказывают про инфраструктуру (Docker, Kubernetes, автоскейлинг) и молчат про состояние в самом приложении. Без этого реплики просто размножат баги.

Забывают про @Scheduled. На трёх подах ежедневная рассылка уходит три раза, это одна из самых частых историй с прода.

Считают масштабирование бесконечным. Узким местом почти всегда становится база, а не сервис: пул соединений, блокировки, тяжёлые запросы.