Микросервисы на собеседовании системного аналитика
Зачем микросервисы на собесе SA
В 2026 микросервисная архитектура — стандарт для большинства российских технологических компаний (Тинькофф, Яндекс, Ozon, X5, ВкусВилл). Системный аналитик на собесе должен показать понимание паттернов, trade-off-ов и типичных проблем.
На собесе системного аналитика микросервисы спрашивают через сценарии: «декомпозируй legacy на микросервисы», «как обеспечишь consistency между сервисами». Слабый ответ — «разделим на маленькие сервисы». Сильный — про bounded contexts, Saga, outbox, observability.
Монолит vs микросервисы
Monolith:
- Один deployable artifact, одна БД
- Простой dev / deploy для small team
- Tightly coupled — изменение в одной части ломает другую
- Scaling: вертикально, лимит = размер машины
Microservices:
- Много независимых сервисов, по своей БД
- Independent deploy / scale
- Loose coupling, изоляция изменений
- Сложнее: network calls, distributed transactions, observability
Когда монолит:
- Стартап до 10-20 разработчиков
- Простая domain
- Скорость > scaling
Когда микросервисы:
- 50+ разработчиков
- Сложная domain с явными bounded contexts
- Independent scaling нужно
Bounded Contexts (DDD)
Domain-Driven Design подход к декомпозиции на микросервисы.
Bounded Context: часть domain с собственной моделью данных и языком (ubiquitous language).
Пример в банке:
- Cards context: card, customer (с т.зрения карты), transaction
- Lending context: loan, customer (с т.зрения кредита), payment
- Same «customer» — разные модели в каждом контексте
Микросервис ≈ один bounded context. Так избегаем «распределённого монолита» (микросервисы, которые знают слишком много друг о друге).
Подробнее — интеграция и архитектура subtopic.
API между сервисами
Synchronous (REST / gRPC):
- Простой request-response
- Latency: каждый hop добавляет
- Coupling: client должен знать о server
Asynchronous (Kafka / RabbitMQ):
- Publish-subscribe
- Loose coupling: publisher не знает consumers
- Eventual consistency
Best practices:
- Service-to-service prefer async для не-critical-path
- Sync только когда нужен immediate response (frontend → backend)
- Idempotency для retry safety
Подробнее — REST API design.
Distributed transactions: Saga
Микросервисы → одна транзакция через несколько БД. Классический 2PC (two-phase commit) плох: blocking, не масштабируется. Saga — pattern для long-running transactions.
Saga: последовательность local transactions, каждая publishes event. Если одна fails — выполняем compensating transactions для уже выполненных.
Choreography: каждый сервис подписан на events, реагирует автономно. Просто, но сложно отлаживать.
Orchestration: central coordinator управляет последовательностью. Сложнее, но видна вся flow.
Пример: order saga = Order created → Reserve inventory → Charge payment → Ship. Если payment fails → compensate inventory (release) → cancel order.
Подробнее — 2PC vs Saga на собесе SA.
Outbox pattern
Атомарно сохранить data + опубликовать event в Kafka невозможно (две системы, нет distributed transactions).
Решение: в одной DB-transaction сохраняем business data + event в outbox таблицу. CDC (Debezium) читает outbox → публикует в Kafka.
Альтернатива: transactional messaging в системах вроде RabbitMQ с native поддержкой.
Eventual consistency
В микросервисах часто строгая consistency недостижима. Eventual consistency: «через какое-то время состояние сходится».
Что это значит для product/UX:
- User видит «order created» в UI до того, как inventory зарезервирован
- Solutions: optimistic UI, async confirmation, compensation flows
Когда нельзя eventual:
- Money: страны строгой regulation требуют strong consistency (Saga + idempotency)
- Auth: token validity не может быть «через секунду»
API Gateway / BFF
API Gateway: entry point, routing к микросервисам. Хендлит auth, rate limit, cors.
BFF (Backend for Frontend): API gateway, customized для конкретного клиента (mobile, web). Aggregates множество backend-сервисов в один API для frontend.
Tools: Kong, Tyk, AWS API Gateway, в России — self-hosted Kong / Apache APISIX.
Подробнее — API gateway BFF на собесе SA.
Observability
В монолите debugging через stack trace. В микросервисах — нет.
Three pillars:
- Logs: структурированные, with correlation IDs
- Metrics: Prometheus + Grafana
- Traces: distributed tracing (Jaeger, Tempo, OpenTelemetry)
Correlation ID: unique ID на каждый request, propagated через все сервисы. В логах и traces используется для restore flow.
Service mesh
Istio, Linkerd, Consul Connect — для service-to-service communication. Provides:
- mTLS между сервисами
- Traffic management (canary, blue/green)
- Observability (auto-traces)
В современных российских командах часто Kubernetes + Istio.
Типичные вопросы
«Декомпозируй монолит банка на микросервисы»
Подход: bounded contexts. Cards, Lending, Payments, KYC, Auth, Notifications. Не разделяй по technical layers (frontend / backend / DB) — по business domains.
«Как обеспечишь consistency между сервисами?»
Eventual consistency через async events + idempotency. Для money flows — Saga с outbox. 2PC избегать.
«Frontend → backend: REST или GraphQL?»
REST — стандарт, лучше caching, public APIs. GraphQL — гибкость, одинаков для разных frontends, BFF-стиль. Часто оба: REST для public, GraphQL внутри BFF.
«Сервис упал — что происходит?»
Circuit breaker для деградации downstream-вызовов. Bulkhead pattern для изоляции resource. Retry с exponential backoff и jitter. Dead-letter queue для failed events.
Частые ошибки
- Distributed monolith. Микросервисы, которые знают слишком много о друг друге. Нельзя deploy independently
- Database per service ignored. Sharing БД = tight coupling. Должна быть private к сервису
- Sync calls для всего. Cascade failure: один сервис лёг → весь chain рухнул
- Без correlation IDs. Debugging в проде = ад
- Decomposition по technical layers. «Микросервис для DB, микросервис для cache» — антипаттерн
FAQ
Сколько микросервисов оптимально?
Зависит от размера команды. Rule of thumb: 1-3 сервиса per team. 100+ микросервисов = ops overhead.
Service mesh обязателен?
Для 10+ микросервисов — желательно. Для 3-5 — overhead не оправдан.
Saga через choreography или orchestration?
Choreography — для простых flows (3-4 шага). Orchestration — для сложных (8+ шагов, branches).
Monorepo или polyrepo?
Polyrepo — независимый CI/CD на сервис. Monorepo — проще обновлять shared-библиотеки. Используют оба подхода.
Когда возвращаться к монолиту?
Если microservices overhead > business value. Известный Amazon Prime Video case: вернулись из микросервисов в монолит для cost optimization.