Сколько микросервисов на проекте

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

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

Как отвечать

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

Дальше механика, которую ждут от Go-разработчика:

• транспорт: gRPC с описанием контракта в protobuf или HTTP, события через брокер для асинхронных связей;
• надёжность: таймауты на каждый вызов, ретраи с ограничением и идемпотентность обработчиков, предохранитель на медленного соседа;
• сквозной контекст: context.Context с отменой и дедлайном, проброшенный до самого низа, трассировка по идентификатору запроса;
• согласованность: паттерн outbox и сага вместо распределённой транзакции;
• эксплуатация: корректное завершение, версионирование контракта без ломающих изменений.

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

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

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

Повторяют миф, будто отказ одного сервиса не влияет на остальные. Без таймаутов, ограниченных ретраев и предохранителя один медленный сервис выест пулы соединений и горутины у всех, кто его вызывает, и упадёт вся цепочка.

Не замечают распределённого монолита: общая база на несколько сервисов, синхронный релиз всей пачкой, общая библиотека с бизнес-логикой. Если так было, назовите это сами и расскажите, чем платили.