Введение в Kafka
Этот модуль нужен, чтобы понять асинхронное взаимодействие между сервисами без магии. Kafka часто называют очередью, но в production она обычно важнее: это распределённый лог событий, через который сервисы обмениваются фактами, разгружают синхронные запросы и строят event-driven процессы.
Kafka помогает там, где один сервис не должен ждать другой в HTTP-запросе. Но она добавляет свои сложности: порядок, партиции, offset, повторная обработка, дубликаты, схемы сообщений, ретраи и наблюдаемость.
Что будет внутри
Разберём брокеры, топики, партиции, offset и retention. Потом перейдём к producers и consumers на Go, consumer groups, rebalancing, retries, DLQ, настройкам и production-деплою.
Минимальная модель, которую стоит держать в голове:
producer -> topic partitions -> consumer group -> обработка с offset
Как понять, что освоил
Вы освоили модуль, если можете объяснить, почему порядок гарантируется только внутри partition, как consumer group делит работу, что будет при падении consumer, зачем нужны idempotency и DLQ, и какие настройки нельзя оставлять бездумно дефолтными.
Рабочие ориентиры
- Kafka хранит события, а не просто "передаёт сообщения". Это влияет на replay, аудит и повторную обработку.
- Событие должно быть бизнес-фактом, а не удалённым вызовом метода в маске.
- Consumer почти всегда должен быть готов к дубликатам. Exactly-once редко означает то, что хочется услышать.
- Порядок, retries, DLQ, схемы, ACL, lag и capacity - часть контракта интеграции, а не "настройки инфраструктуры потом".
- В проекте RateDesk Kafka появляется как integration event
RateUpdated: теория объясняет trade-offs, а конкретные задачи остаются в проектном треке.