Был ли сервис в продакшене с одной или несколькими репликами

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

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

Как отвечать

Опирайтесь на свой опыт: сколько было реплик, где они работали (Kubernetes, виртуалки за балансировщиком), какая была нагрузка. Затем покажите, что понимаете последствия:

• состояние вне процесса: кеш, сессии, счётчики rate limit в памяти у каждой реплики свои. Общее выносят в Redis или базу;
• фоновые задачи: крон внутри сервиса запустится на каждой реплике. Нужна блокировка (например, pg_try_advisory_lock в PostgreSQL), выбор лидера или отдельный CronJob;
• корректное завершение: ловить SIGTERM через signal.NotifyContext, перестать проходить readiness, дождаться текущих запросов через http.Server.Shutdown. По умолчанию Kubernetes ждёт 30 секунд, потом шлёт SIGKILL;
• пробы: readiness снимает под с трафика, liveness его перезапускает. Если в liveness проверять базу, её сбой перезапустит все реплики разом;
• идемпотентность: повтор запроса может прийти на другую реплику, а сообщение из очереди обработаться дважды;
• миграции: выполняются один раз отдельным шагом, а не каждой репликой при старте.

Если сервис всегда жил в одной реплике, так и скажите и объясните почему: внутренний сервис с низкой нагрузкой, допустимый простой при деплое. Затем расскажите, что пришлось бы поменять для масштабирования. Цифры приводите свои, а не шаблонное «производительность выросла на 40%».

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

Путают реплики stateless-сервиса с репликацией базы данных. Это разные темы, и смешивать их в ответе не стоит.

Не вспоминают про фоновые задачи, а потом удивляются, что письмо ушло пользователю трижды.

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