Какие недостатки микросервисной архитектуры существуют кроме сложности согласованности данных

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

Умеете ли вы критически смотреть на модную архитектуру, и, раз вопрос задают тестировщику, понимаете ли, во что она превращает тестирование. Формулировка «кроме согласованности данных» отсекает заученный ответ. Следом идёт практика: как бы вы тестировали такую систему и как ловили бы баг, который воспроизводится раз в неделю.

Как отвечать

Соберите минусы по группам, каждый с механикой, а не с ярлыком «сложнее»:

• эксплуатация: десятки пайплайнов, конфигов, наборов секретов и дежурств. Нужны платформенная команда и шаблоны сервисов, иначе сопровождение съедает выигрыш;
• ненадёжная сеть: любой вызов может зависнуть. Нужны таймауты, ретраи с джиттером, идемпотентность обработчиков и предохранитель, иначе один медленный сервис кладёт цепочку. Латентность растёт: последовательный вызов пяти сервисов складывает их хвосты, и p99 портится сильнее среднего;
• диагностика: без сквозной трассировки и общего идентификатора запроса причину ошибки искать негде. Логи нужны централизованные;
• контракты: несовместимая правка API ломает соседей. Спасают версионирование, обратная совместимость и контрактные тесты (Pact), а не переписка в чате;
• тестовые окружения: полный стенд дорог и нестабилен, отсюда флак в автотестах. Помогают контрактные тесты, стабы, тестовые контейнеры и проверки на проде за фича-флагом;
• подготовка данных: сценарий требует согласованных записей в нескольких базах, одним INSERT его уже не подготовить;
• организация: границы сервисов повторяют структуру команд, и неверная нарезка даёт распределённый монолит, где ничего нельзя выкатить по отдельности.

Хорошо закончить тем, что монолит с чистыми модулями часто выгоднее, а микросервисы окупаются от размера команды.

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

Отвечают «стало сложнее» и останавливаются. Интервьюер ждёт механику: что именно сложнее, где это болит и чем лечится.

Называют микросервисами систему, где сервисы ходят в одну общую базу. Это распределённый монолит с минусами обоих подходов.

Считают, что достаточно юнит-тестов внутри сервиса. Больше всего дефектов живёт на стыках, и именно они не покрыты, когда каждая команда тестирует только себя.