Источник
Практический кейс из главы 9
Distributed Message Queue как базовый примитив для асинхронной интеграции сервисов.
Distributed Message Queue - базовый инфраструктурный примитив для асинхронной интеграции. Он позволяет развязать продюсеров и консьюмеров по времени, сгладить burst-нагрузку и сделать обработку устойчивой к частичным сбоям. На интервью кейс проверяет понимание delivery semantics, ordering, retry/DLQ и backpressure.
Примеры систем очередей
- Apache Kafka: partitioned log, consumer groups, replay и event streaming
- RabbitMQ: routing/queues/exchanges, гибкие delivery guarantees
- Apache Pulsar: separated storage/compute, multi-tenant topics
- NATS JetStream: лёгкая шина с persisted streams
- AWS SQS/SNS: managed messaging для cloud-native сценариев
Функциональные требования
Core API
POST /topics/:name/messages- publishGET /topics/:name/poll- consumePOST /offsets/commit- commit offsetPOST /topics/:name/replay- replay by offset
Надёжность обработки
- Consumer groups для параллельной обработки
- Retry topics + DLQ для проблемных сообщений
- Гарантии доставки (at-least-once baseline)
- Backpressure и throttling при всплесках
Нефункциональные требования
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Throughput | Высокий под burst-нагрузкой | Сглаживание пиков и decoupling сервисов |
| Latency | Контролируемый end-to-end lag | SLO по времени доставки событий |
| Scalability | Линейно по partition | Рост без полного redesign |
| Durability | Replicated log | Переживать отказ брокера/узла |
| Reliability | At-least-once baseline | Предсказуемая обработка при ошибках |
High-Level Architecture
Базовый контур DMQ: ingress через broker frontend, partitioned replicated log и delivery-контуры consumer groups с retry/DLQ.
Глубже
Kafka (book summary)
Подробно про partitioned log, consumer groups, replication и operational trade-offs.
Architecture Map
partitioned log + consumer groups + retry/DLQСхема показывает publish path, consume path и контур обработки проблемных сообщений.
Data Model Map
Структура события в очереди и логика размещения в partitioned log.
Message Envelope
key
order:1234
payload
{ status: "created", amount: 9900 }
headers
Log Placement
partitioning
hash(key) -> topic: orders / partition: 7
offsets
offset: 912334 (append-only)
retention
7d / 100GB per partition / compaction
Ordering
Гарантируется внутри partition, но не между partition.
Replay
Offset позволяет восстановить обработку после сбоя consumer.
Idempotency
`message_id` помогает дедуплицировать повторные delivery.
Read / Write Path через компоненты
Интерактивный flow: как событие проходит publish path до durable ack и как consumer читает, обрабатывает и коммитит offset c fallback в retry/DLQ.
Read/Write Path Explorer
Интерактивный разбор publish/consume path через ключевые компоненты distributed message queue.
Write path
- Partition key определяет ordering-домен и распределение нагрузки по partition-ам.
- Ack policy (leader vs quorum) задаёт баланс latency и durability.
- Producer batching и compression обычно критичны для throughput под burst-нагрузкой.
- Replication lag нужно мониторить отдельно от end-to-end consumer lag.
Риски и типовые ошибки
- Global ordering: обещать глобальный порядок без объяснения цены и ограничений.
- Retry storms: отсутствие bounded retry и backoff перегружает кластер.
- Duplicate effects: отсутствие idempotent consumers при at-least-once.
- Poison messages: нет DLQ/карантина и процедур ручного разбора.
- Wrong metrics: путать broker throughput с end-to-end processing latency.
Что важно проговорить на интервью
- Границы ordering: внутри partition vs глобально.
- Выбранные delivery semantics и почему они приемлемы для бизнес-кейса.
- Стратегия offset commit и поведение после consumer crash.
- Политика retry/DLQ и как организован safe replay.