Distributed Message Queue

Зачем нужно знать

Распределенная очередь сообщений нужна, когда система должна принимать события быстрее, чем downstream-сервисы успевают их обработать, и при этом не терять данные. Это базовый компонент event-driven architecture: платежи публикуют события для аналитики, логирование пишет миллионы записей в секунду, CDC переносит изменения из базы, ML pipeline читает историю повторно, а consumer groups независимо обрабатывают один и тот же поток.

Kafka-like очередь важна тем, что это не просто брокер с push-доставкой. Это распределенный commit log с partition ordering, durable retention, replay by offset, consumer groups, replication и контролируемой моделью подтверждений. На интервью этот кейс проверяет понимание диска, page cache, batching, backpressure, consumer lag, leader election, quorum writes и exactly-once semantics.

Масштаб кейса: десятки тысяч topics, сотни тысяч partitions, сотня brokers, миллионы сообщений в секунду, replication factor 3, retention на дни и многократный fan-out на consumer groups. При таком масштабе bottleneck часто не CPU, а сеть, disk bandwidth, количество partitions на broker, размер batches и количество rebalance events.

Связанные темы: [CONCEPT]queues, Kafka Broker Internals, [CONCEPT]replication, [CONCEPT]consensus-overview, [CONCEPT]partitioning-strategies.

Mental model

Ментальная модель Kafka-like системы: topic разбит на partitions, каждая partition является append-only log. Producer выбирает partition по key hash или custom partitioner, отправляет batch лидеру partition, лидер пишет batch в segment file, followers догоняют лидер через replication fetch, а consumer читает по offset.

Ordering гарантируется только внутри одной partition. Если все сообщения одного заказа имеют одинаковый key order_id, они попадут в одну partition и сохранят порядок. Если key не задан или распределяется случайно, глобального порядка нет. Это не bug, а цена горизонтального масштабирования.