Разбор сложных вопросов по микросервисной архитектуре: паттерны Saga, Outbox, Service Mesh и распределенные транзакции. Подготовка к интервью.
На собеседованиях уровня Middle+ больше не спрашивают «что такое микросервис». Интервьюеры фокусируются на границах ответственности сервисов и способах их взаимодействия в условиях высокой нагрузки. Если в 2022 году стандартом был простой REST, то сегодня в крупных проектах (Ozon, Avito, Тинькофф) доминируют gRPC для внутреннего взаимодействия и асинхронные события через Kafka или Pulsar.
Один из самых сложных блоков вопросов касается обеспечения целостности данных без использования распределенных блокировок (2PC), которые практически не масштабируются.
Кандидат должен уметь различать два типа реализации Saga:
Частый вопрос: как гарантировать, что сообщение уйдет в брокер (Kafka) только если запись в БД прошла успешно? Решение через Outbox-таблицу в той же БД и отдельный Relay-процесс (например, Debezium) считается стандартом индустрии. Использование CDC (Change Data Capture) позволяет избежать потери данных при сбоях сети между приложением и брокером.
К 2026 году использование Service Mesh стало стандартом для систем, где количество микросервисов превышает 50–70 единиц. На интервью важно понимать:
Вместо простого логирования сейчас обсуждают OpenTelemetry. На собеседовании могут попросить спроектировать систему трассировки, которая не «положит» хранилище логов при резком всплеске трафика. Здесь важно упомянуть Sampling (выборочное сохранение трасс) и Adaptive Sampling, когда система сохраняет больше данных только в моменты аномалий.
Типовая задача: «У нас есть монолит на 2 млн строк кода, как вы будете выделять из него первый микросервис?». Правильный ответ базируется на паттерне Strangler Fig (Фига-душитель). Сначала выделяется функционал, который меньше всего связан с ядром БД, ставится API Gateway или Proxy, который постепенно перенаправляет запросы в новый сервис. Важно обсудить синхронизацию данных в переходный период и стратегию отката.
В 2026 году Senior-инженер должен думать о деньгах. Вопросы могут касаться:
API Gateway работает на «входе» в систему (North-South трафик): авторизация внешних пользователей, лимитирование запросов (Rate Limiting), трансформация протоколов. Service Mesh управляет внутренним взаимодействием (East-West трафик): взаимная аутентификация сервисов, балансировка нагрузки внутри кластера, продвинутый роутинг и наблюдаемость.
Основной способ — использование уникального ключа идемпотентности (Idempotency Key), который клиент или продюсер генерирует для каждой операции. На стороне потребителя проверяется наличие этого ключа в БД (например, в Redis или основной таблице) перед выполнением бизнес-логики. В 2026 году также популярно использование функционала идемпотентных продюсеров в Kafka.
Это система, где сервисы разделены физически, но сильно связаны логически: изменение в одном требует синхронного деплоя остальных. Признаки: общая база данных, синхронные цепочки вызовов через 4+ сервиса, отсутствие версионирования контрактов. Избегается через Domain-Driven Design (DDD) и четкое определение Bounded Contexts.
Использовать механизмы Resource Quotas и LimitRanges для жесткого ограничения ресурсов. Также важно настраивать PriorityClasses, чтобы критически важные сервисы вытесняли менее приоритетные при дефиците мощностей на ноде.
Если команда маленькая (до 10-15 человек), бюджет на инфраструктуру ограничен или доменная область еще не стабилизировалась. На ранних этапах стартапа монолит позволяет быстрее менять бизнес-логику без затрат на поддержку распределенной системы.
