Какие недостатки у микросервисной архитектуры?

Главные недостатки микросервисов — это сложность распределённой системы: сетевые задержки, согласованность данных, операционная нагрузка и сложность отладки.

1. Сложность распределённой системы — приходится решать проблемы сетевых задержек, отказов сети, согласованности данных, что гораздо сложнее, чем вызов метода в монолите.

2. Сложность управления данными — невозможно использовать обычные ACID-транзакции между сервисами. Приходится применять паттерн Saga, eventual consistency, что значительно усложняет логику.

3. Операционная сложность — необходимо организовать мониторинг, логирование, трассировку для десятков или сотен сервисов. Нужна зрелая DevOps-культура и CI/CD.

4. Сетевые задержки — вызов между сервисами по сети значительно медленнее вызова метода в рамках одного процесса.

5. Сложность тестирования — интеграционное и E2E-тестирование становятся гораздо сложнее. Необходимо использовать contract testing (Pact), testcontainers, моки внешних сервисов.

6. Дублирование кода — некоторые общие функции (например, валидация, маппинг DTO) приходится дублировать в разных сервисах или выносить в shared-библиотеки, что создаёт связность.

7. Сложность отладки — один бизнес-процесс может проходить через 5-10 сервисов, и для отладки нужны инструменты распределённой трассировки.

8. Overhead на межсервисное взаимодействие — сериализация/десериализация данных, HTTP/gRPC-вызовы, брокеры сообщений добавляют накладные расходы.

9. Проблема «распределённого монолита» — при неправильной декомпозиции можно получить систему с недостатками и монолита, и микросервисов одновременно.

На собеседовании: знание недостатков ценится даже выше, чем знание преимуществ — оно показывает реальный опыт. Частая ошибка — не упомянуть distributed monolith и проблему eventual consistency.