Интеграции и архитектура на собеседовании системного аналитика
Зачем SA знать архитектурные паттерны
SA проектирует интеграции — как сервисы общаются, через какие протоколы, кто за что отвечает. Без архитектурного словаря невозможно вести разговор с инженерами и принимать решения.
На собесе системного аналитика архитектура — обязательный блок, 60-90 минут. Junior — знает основные термины; middle — может сравнить варианты архитектуры; senior — проектирует с нуля и обосновывает trade-off-ы.
Монолит vs Микросервисы
Монолит. Все в одном приложении / БД.
Плюсы:
- Простота разработки и деплоя
- Транзакции локальные (ACID)
- Быстрый старт
Минусы:
- Сложно масштабировать команду
- Любое изменение — полный релиз
- Технологический lock-in
Микросервисы. Сервисы независимые, у каждого своя БД, общение через сеть.
Плюсы:
- Независимое развитие команд
- Полиглот (разные технологии)
- Independent scaling
Минусы:
- Сложность операций (deploy, monitoring, debugging)
- Distributed transactions
- Network latency
- Eventual consistency
На собесе: «Начинать с монолита. Микросервисы — когда команда не справляется с координацией».
Паттерны интеграции
Request-response (sync). Сервис A → REST/gRPC → Сервис B → ответ → A.
- Простой
- Tight coupling (A ждёт B)
- Failure cascading
Event-driven (async). Сервис A → event в Kafka/RabbitMQ → Сервис B обрабатывает.
- Loose coupling
- Async, A не ждёт B
- Eventual consistency
- Сложнее debug
Saga. Несколько локальных транзакций с compensating actions. Подробнее в distributed-systems.
CQRS. Command-Query Responsibility Segregation. Запись в одной модели, чтение из другой (eventually consistent).
Event sourcing. Не храним current state, храним лог событий. State восстанавливается путём replay.
API Gateway
Точка входа для всех клиентских запросов. Между клиентом и микросервисами.
Функции:
- Routing (направить запрос правильному сервису)
- Authentication / authorization
- Rate limiting
- Caching
- Logging / monitoring
- Protocol translation (REST для клиента → gRPC для backend)
Популярные: Kong, AWS API Gateway, Apigee, Yandex API Gateway.
Подробнее — API Gateway и BFF.
BFF (Backend For Frontend)
Специализированный gateway для конкретного типа клиента (mobile, web, partner API).
Зачем:
- Mobile хочет одного формата (компактный, для слабой сети)
- Web — другого (богаче, с агрегацией)
- Partner API — третий (стабильный контракт, версионированный)
Альтернатива: один gateway + aggregation/transformation в нём. Сложнее, но меньше дублирования.
Message brokers
Apache Kafka. Distributed log. Высокий throughput, persistent. Для event streaming, audit logs, microservice integration.
RabbitMQ. Traditional message queue. Гибкая маршрутизация (exchanges, queues, bindings). Для task queues, RPC.
Redis Streams. Лёгкий, in-memory с persistence. Хорош для real-time.
SQS / Service Bus. Cloud-managed очереди.
Выбор:
| Use case | Подходит |
|---|---|
| Event streaming, миллионы msg/sec | Kafka |
| Task queue, complex routing | RabbitMQ |
| Real-time, low latency | Redis Streams |
| Cloud-native, AWS | SQS |
Synchronous vs Asynchronous
Sync вызовы: A зовёт B напрямую, ждёт ответа.
Когда подходит:
- Read-операции (нужен немедленный результат)
- Простые цепочки (2-3 сервиса)
- Когда latency критична
Когда не подходит:
- Длинные цепочки (latency накапливается, любой failure кешит всё)
- Heavy load (один медленный сервис тормозит всю систему)
Async вызовы: A публикует событие, B обрабатывает потом.
Когда подходит:
- Длинные процессы (notifications, аналитика)
- Decoupling сервисов
- Нужна масштабируемость
Когда не подходит:
- UI ждёт результат (нужен sync или WebSocket)
- Простые операции (избыточная сложность)
Pull vs Push
Pull (polling). Клиент периодически спрашивает «новые данные?».
- Простой
- Может быть latency (если опрашивает редко)
- Нагрузка на сервер если опрашивает часто
Push (через WebSocket, SSE, push-notification).
- Real-time
- Сложнее реализация
- Сервер должен помнить subscribers
Идемпотентность интеграций
Подробнее в distributed systems. Для интеграций важно:
- POST / PUT — идемпотентен через idempotency-key
- Async — обработка должна быть идемпотентной (UPSERT по message ID)
- Retry с backoff
- Dead letter queue для сообщений, которые многократно не обработались
Cache patterns
Cache-aside. App читает cache. Если miss — читает БД, кладёт в cache.
Read-through. App читает cache. Cache сам подгружает из БД при miss.
Write-through. App пишет в cache, cache пишет в БД. Consistency.
Write-behind. App пишет в cache. Cache асинхронно пишет в БД. Performance, риск потери.
Invalidation strategies:
- TTL (Time-to-Live)
- Manual (после write — delete cache)
- Event-driven (через event invalidate cache в других сервисах)
Подробнее — Cache strategies.
Типичные вопросы
«Зачем нужен API Gateway?»
Точка входа: routing, auth, rate limit, logging. Без gateway — каждый сервис делает это сам, дублирование. С gateway — централизация.
«Когда нужны микросервисы vs монолит?»
Микросервисы — когда (1) команда > 10 человек, (2) разные части продукта развиваются независимо, (3) нужна полиглотная стек. Иначе — монолит, проще.
«Sync vs async — пример»
Sync: «получи список заказов клиента» — нужен немедленно.
Async: «после оформления заказа отправь email» — клиенту не нужно ждать.
«Что такое idempotent consumer в Kafka?»
Consumer обрабатывает каждое сообщение как UPSERT по unique ID. Если получает дубликат — no-op. Защита от at-least-once delivery.
«Спроектируй интеграцию маркетплейса с банком»
Архитектура: API Gateway → Order Service → publishes event "order_paid" → Payment Service подхватывает → вызывает банк API через resilient client (retry + circuit breaker) → пишет result event → Order Service обновляет статус.
Частые ошибки
- Микросервисы сразу. Premature decomposition. Начни с monolith, разделяй когда болит.
- Event-driven для всего. Async — это сложность. Не каждой интеграции нужно.
- Игнорировать failure modes. Что если сервис недоступен? Что если message lost? Что если duplicate?
- API Gateway = monolith inside. Не пихай бизнес-логику в gateway. Это маршрутизация.
- Один cache для всех. Разные данные имеют разный TTL и invalidation. Один cache != лучший.
FAQ
Какие книги читать?
«Building Microservices» (Sam Newman) — фундамент. «Microservices Patterns» (Chris Richardson) — детально. «Designing Data-Intensive Applications» (Kleppmann) — глобальная картина.
Нужно ли уметь развёртывать?
SA — нет. Это работа DevOps. SA нужно понимать концепции (Docker, Kubernetes, CI/CD) для общения.
Спрашивают ли service mesh?
На senior — да (Istio, Linkerd). Базовое понимание роли (security, observability, traffic management).
Что важно для собеса в банке?
Distributed transactions (2PC vs Saga), idempotency, audit, compliance. Меньше про event-driven streaming.
Сколько готовиться?
С нуля — 2-3 месяца. Уже работал — 2-4 недели.