Антипаттерны микросервисов на собеседовании системного аналитика

Зачем спрашивают на собесе SA

Антипаттерны — критическое знание в micro-services. На собесе SA: «когда не нужны микросервисы», «distributed monolith».

Distributed monolith

Сервисы tightly coupled — одно изменение требует deploy multiple services.

Symptoms:

• Каждый release — coordinated deploy 5+ servisов.
• Shared library с domain logic.
• Один сервис fails → всё валится.
• Cannot deploy independently.

Худшее из обоих миров. Network overhead microservices + tight coupling monolith.

Лечение. Decouple — events vs sync, separate domain models, contracts.

Shared database

Multiple services reading / writing same DB.

Symptoms:

• Service A не может change schema без consultation Service B.
• DB — bottleneck.
• Migrations coordinate-fest.

Лечение.

• Each service — own DB.
• Communication через API / events.
• Data sync через CDC если нужна reporting.

Sync RPC chains

Service A → Service B → Service C → Service D

Problems:

• Latency складывается.
• Failure любой → fail.
• Hard to scale (bottleneck on slowest).

Solutions:

• Async events где возможно.
• Aggregator service / BFF combining results.
• Caching между calls.
• Choreography в Saga vs orchestration.

Nano-services

Слишком гранулярно.

Symptoms:

• 50 microservices на команду из 5.
• Один service has 1 endpoint.
• Сервисы постоянно вызывают друг друга.
• Operational overhead огромный.

Эмпирика. Two-pizza team per service. Меньше = consolidate.

Wrong boundaries

Bounded contexts не right.

Symptoms:

• Cross-cutting changes требуют изменения 5 сервисов.
• Frequent inter-service calls.
• Same domain entity в multiple services с conflicting models.

Лечение. Re-think DDD. Identify правильные boundaries.

Premature microservices

Стартап с 3 разработчиками + 20 microservices.

Symptoms:

• Operational overhead убивает velocity.
• Каждый новый dev tackles infra weeks.
• Outage debugging across сервисов.
• 80% time на ops, 20% — features.

Эмпирика.

• Start с monolith.
• Split когда:
  • Team > 10 developers.
  • Domain становится явно separable.
  • Specific scale needs.

«Monolith first» (Martin Fowler).

Связанные темы

• Монолит vs микросервисы для SA
• DDD для SA
• Service mesh для SA
• API Gateway и BFF для SA
• Подготовка к собесу системного аналитика

FAQ

Когда оправданы микросервисы?

Большая компания, multiple teams independently shipping, scale needs different per service.

Это официальная информация?

Нет. Статья основана на работах Sam Newman («Building Microservices»), Martin Fowler, microservices.io.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.