Apache Kafka

Apache Kafka — это распределенная платформа для передачи и хранения потоков событий. Она позволяет приложениям публиковать сообщения, сохранять их в упорядоченном журнале и передавать другим сервисам для последующей обработки.

Kafka часто используется в микросервисной архитектуре, Data Pipeline, Event-driven Architecture, системах аналитики, мониторинга, логирования и интеграции сервисов. Особенно полезна она там, где события поступают постоянно и должны надежно обрабатываться несколькими независимыми потребителями.

Например, интернет-магазин после оформления заказа публикует событие OrderCreated. Один сервис отправляет письмо клиенту, второй обновляет аналитику, третий резервирует товар, а четвертый передает информацию в CRM.

Что такое Apache Kafka простыми словами

Kafka можно представить как общий поток событий между программами.

Один сервис пишет в него сообщения, а другие сервисы читают их независимо друг от друга.

Order Service
 ↓
OrderCreated
 ↓
Apache Kafka
 ↓
Email Service
Analytics Service
Warehouse Service

Главное отличие от простой передачи HTTP Request заключается в том, что отправителю не обязательно напрямую знать всех получателей.

Kafka помогает разделить сервис, который создает событие, и сервисы, которые должны на него реагировать.

Для чего используется Kafka

• интеграция микросервисов;
• Event-driven Architecture;
• Data Pipeline;
• передача логов и событий;
• потоковая аналитика;
• обработка действий пользователей;
• синхронизация данных между системами;
• передача изменений из баз данных;
• интеграция CRM, ERP и других бизнес-систем;
• обработка больших потоков сообщений.

Что такое событие

Event описывает факт, который уже произошел.

Например:

• пользователь зарегистрировался;
• заказ создан;
• платеж подтвержден;
• товар закончился;
• документ изменен.

Событие обычно содержит тип, идентификатор, время и данные, необходимые получателю.

{
 "event_type": "OrderCreated",
 "order_id": 501,
 "customer_id": 125,
 "created_at": "2026-08-17T09:00:00Z"
}

Producer

Producer — приложение, которое публикует сообщения в Kafka.

Например, order-service после успешного создания заказа отправляет событие OrderCreated.

Producer определяет Topic и передает сообщение Kafka Broker.

Consumer

Consumer — приложение, которое читает сообщения.

Например, email-service получает OrderCreated и отправляет клиенту подтверждение.

Один и тот же поток могут независимо читать разные Consumers.

Topic

Topic — логический поток сообщений определенного типа.

Например:

orders
payments
user-events
inventory-events

Producer записывает событие в Topic, а Consumers подписываются на нужные Topics.

Kafka Broker

Broker — сервер Kafka, который принимает, хранит и отдает сообщения.

В production обычно используется несколько Brokers, формирующих Kafka Cluster.

Так данные и нагрузка могут распределяться между серверами.

Kafka Cluster

Kafka Cluster — группа Brokers, работающих как единая система.

Topics распределяются по кластеру, а данные могут реплицироваться для повышения отказоустойчивости.

Клиент взаимодействует с кластером через Kafka Protocol, а не обязан вручную определять физическое расположение каждого сообщения.

Partition

Topic делится на Partitions.

Partition — упорядоченный журнал сообщений.

Разделение позволяет распределять нагрузку между Brokers и Consumers.

Topic: orders
Partition 0: event1 → event2 → event3
Partition 1: event4 → event5 → event6

Количество Partitions влияет на масштабирование и параллелизм обработки.

Почему нужны Partitions

Если бы весь Topic существовал только как один поток на одном сервере, его возможности масштабирования были бы ограничены.

Partitions позволяют распределить сообщения и обрабатывать несколько частей потока одновременно.

Но большое количество Partitions также увеличивает эксплуатационную сложность, поэтому их количество следует планировать под нагрузку.

Offset

Offset — позиция сообщения внутри конкретной Partition.

Consumer запоминает, до какого Offset он обработал события.

Благодаря этому после перезапуска приложение может продолжить чтение с нужной позиции.

Kafka как журнал событий

Kafka отличается от простого механизма моментальной передачи сообщений тем, что хранит события определенное время.

Consumer может отключиться, а затем вернуться и продолжить чтение сохраненного журнала.

Это также позволяет повторно обработать историю событий, если такая возможность предусмотрена архитектурой.

Retention

Retention определяет, как долго или до какого объема Kafka хранит сообщения.

Событие не обязательно удаляется сразу после прочтения Consumer.

Например, Topic может сохранять историю определенный период, чтобы сервисы могли повторно ее обработать.

Kafka и обычная очередь сообщений

Kafka часто сравнивают с Message Queue, но модели отличаются.

Это обобщенное сравнение: конкретные возможности зависят от выбранных продуктов и архитектуры.

Consumer Group

Consumer Group объединяет несколько экземпляров одного логического Consumer.

Partitions распределяются между участниками группы, поэтому обработка может выполняться параллельно.

Например, email-service запущен в четырех экземплярах, и каждый получает часть Partitions Topic.

Consumer Group и масштабирование

Если Topic имеет несколько Partitions, можно запускать несколько Consumers в одной Group.

Kafka распределяет работу между ними.

Это позволяет масштабировать обработку по мере роста потока сообщений.

При этом количество активных Consumers, которые действительно получают отдельные Partitions, связано с количеством доступных Partitions.

Несколько Consumer Groups

Один Topic могут независимо читать несколько Consumer Groups.

Например, OrderCreated обрабатывают:

• email-service;
• analytics-service;
• warehouse-service.

Каждый сервис использует свою Consumer Group и имеет собственную позицию чтения.

Порядок сообщений

Kafka обеспечивает упорядоченность сообщений внутри одной Partition.

Глобальный порядок между разными Partitions автоматически не возникает.

Это важное ограничение при проектировании событий, которым нужна строгая последовательность.

Message Key

Producer может передать Key вместе с сообщением.

Key часто используется для выбора Partition.

Например, все события одного order_id можно направлять в одну Partition, чтобы сохранить их относительный порядок.

key = order_501
OrderCreated
PaymentConfirmed
OrderShipped

Выбор Key влияет на распределение нагрузки.

Проблема Hot Partition

Если слишком большое количество событий получает один и тот же или неравномерно распределенный Key, основная нагрузка может оказаться в одной Partition.

Так появляется Hot Partition.

При проектировании Key необходимо учитывать как порядок, так и равномерность распределения сообщений.

Replication

Kafka может хранить копии Partition на нескольких Brokers.

Replication помогает продолжить работу при отказе отдельного сервера.

Количество копий выбирается исходя из требований к надежности и доступным ресурсам.

Leader и Replica

Для Partition один Broker выполняет основную роль, а другие могут хранить копии.

Producer и Consumer работают через актуального лидера соответствующей Partition согласно внутреннему механизму Kafka.

При отказе узла кластер может использовать подходящую реплику.

Replication не заменяет Backup

Репликация защищает прежде всего от отказа отдельных компонентов.

Если приложение опубликовало ошибочные события или оператор изменил настройки Retention, проблема может затронуть весь Cluster.

Для действительно критичных данных необходимо отдельно продумывать восстановление и исходный Source of Truth.

Delivery Semantics

При работе с Kafka важно понимать, сколько раз сообщение может быть обработано.

В распределенных системах часто обсуждают модели At-most-once, At-least-once и Exactly-once.

Конкретные гарантии зависят не только от Kafka, но и от Producer, Consumer и бизнес-операций.

At-most-once

При At-most-once сообщение обрабатывается не более одного раза, но при сбое потенциально может быть потеряно.

Такая модель подходит только для данных, где потеря события допустима.

At-least-once

At-least-once означает, что система стремится не потерять сообщение, но отдельные события могут быть обработаны повторно.

Это распространенная модель в распределенных системах.

Поэтому Consumer должен учитывать возможность Duplicate.

Exactly-once

Exactly-once — более сложная семантика, цель которой состоит в предотвращении повторного эффекта при определенных операциях обработки.

Однако нельзя автоматически предполагать, что внешний API, SQL Database и Kafka вместе образуют Exactly-once бизнес-процесс.

Граница гарантий должна анализироваться для всей цепочки.

Идемпотентность Consumer

Consumer желательно проектировать так, чтобы повтор одного сообщения не создавал неправильный результат.

Например, событие PaymentConfirmed не должно дважды увеличивать баланс.

Для этого используют Event ID, UNIQUE Constraints, таблицы обработанных событий или другую модель дедупликации.

Duplicate Events

Повторные события являются нормальным сценарием, который нужно учитывать в надежной архитектуре.

Причиной могут быть Retry, ошибка подтверждения или перезапуск Consumer.

Система должна быть готова корректно обработать повтор.

Producer Acknowledgement

Producer может требовать различный уровень подтверждения того, что сообщение принято инфраструктурой.

Более строгие требования повышают надежность, но могут увеличить latency.

Настройка должна соответствовать критичности событий.

Retry Producer

Если отправка временно не удалась, Producer может повторить операцию.

Retry помогает при кратковременных сетевых проблемах.

Но параметры повторов и Timeout необходимо ограничивать, иначе деградация Kafka может привести к большим очередям запросов в приложении.

Consumer Offset Commit

Consumer должен решить, когда считать сообщение успешно обработанным.

Если Offset подтвержден до выполнения бизнес-операции, сбой после Commit Offset может привести к пропуску обработки.

Если Offset фиксируется после операции, возможна повторная обработка после сбоя.

Поэтому порядок действий зависит от требуемой семантики.

Kafka и Database Transaction

Обычная SQL Transaction не охватывает автоматически Kafka и Database одновременно.

Например, order-service сохраняет заказ в PostgreSQL, затем должен отправить OrderCreated.

Если COMMIT базы успешен, а отправка Kafka не удалась, другие сервисы не узнают о заказе.

Transactional Outbox

Transactional Outbox — распространенный способ решить проблему согласованности между базой и публикацией событий.

Backend в одной ACID Transaction сохраняет заказ и запись в Outbox Table.

Отдельный процесс читает Outbox и отправляет событие в Kafka.

После успешной публикации запись помечается обработанной.

Это уменьшает риск расхождения между Database State и Event Stream.

Change Data Capture

Change Data Capture, или CDC, позволяет отслеживать изменения в базе данных и преобразовывать их в поток событий.

Например, INSERT или UPDATE в PostgreSQL может стать событием, которое отправляется в Kafka.

CDC используется для интеграций, аналитики и синхронизации систем.

Kafka и Data Pipeline

Kafka часто становится транспортным слоем Data Pipeline.

Источники публикуют данные, а несколько Consumers преобразуют и передают их дальше.

CRM → Kafka → Data Warehouse
Website → Kafka → Analytics
Database CDC → Kafka → Search Index

Так источники и получатели меньше зависят друг от друга.

Kafka и ETL

В традиционном ETL данные периодически извлекаются, преобразуются и загружаются пакетами.

Kafka позволяет строить потоковый вариант, где изменения поступают почти постоянно.

При этом Batch ETL и Streaming могут использоваться вместе.

Stream Processing

Stream Processing означает обработку данных по мере их появления.

Например, система получает платежные события и почти сразу рассчитывает показатели или обнаруживает подозрительную активность.

Kafka обеспечивает поток и хранение событий, а обработка может выполняться специализированными приложениями или Streaming Framework.

Kafka Streams

В экосистеме Kafka существует подход к созданию приложений, которые читают Topics, преобразуют события и записывают результат обратно в Kafka.

Например, поток заказов можно группировать по магазинам и получать агрегированный поток продаж.

Такая обработка полезна для near real-time аналитики.

Event Time и Processing Time

В потоковых системах важно различать время самого события и время его обработки.

Событие могло произойти в 10:00, но попасть в обработку в 10:05 из-за сетевой задержки.

Для аналитики обычно важно заранее определить, какое время используется в расчетах.

Schema сообщений

События должны иметь понятный контракт.

Если Producer внезапно изменит название поля или тип данных, Consumers могут перестать работать.

Поэтому Event Schema должна проектироваться так же внимательно, как REST API Contract.

JSON в Kafka

Сообщения Kafka часто сериализуются в JSON благодаря простоте и читаемости.

{
 "order_id": 501,
 "status": "paid"
}

Но JSON занимает больше места, чем некоторые бинарные форматы, и предоставляет менее строгую схему без дополнительных инструментов.

Avro и другие форматы

Для потоков событий могут использоваться бинарные форматы со схемой.

Они позволяют явно описывать поля и типы и эффективнее передавать большие объемы данных.

Выбор формата зависит от требований к совместимости, размеру сообщений и экосистеме.

Schema Evolution

Схема события развивается вместе с приложением.

Например, в OrderCreated появляется новое поле source.

Новый Producer должен по возможности не ломать старых Consumers.

Поэтому при проектировании Event Contract важно учитывать Backward Compatibility и Forward Compatibility.

Версионирование событий

Есть несколько подходов: добавление необязательных полей, отдельная версия Schema или новый Event Type.

Выбор зависит от масштаба изменений.

Главное — не изменять смысл существующего события неожиданно для всех Consumers.

Kafka и Event-driven Architecture

Event-driven Architecture строится вокруг событий как способа связи компонентов.

Сервис публикует факт события, а заинтересованные Consumers реагируют самостоятельно.

Это уменьшает прямую связанность между сервисами.

Преимущества слабой связанности

Order Service не обязан знать адрес Email Service или Analytics Service.

Он публикует OrderCreated, а новые Consumers можно добавлять без изменения Order Service.

Это упрощает развитие больших распределенных систем.

Недостатки Event-driven Architecture

Слабая связанность усложняет наблюдаемость и отладку.

Одна пользовательская операция может пройти через несколько Topics и Consumers.

Также необходимо учитывать Duplicate, порядок, задержки, Retry и Poison Messages.

Kafka и микросервисы

Kafka часто используется как асинхронный транспорт между Microservices.

Синхронные операции могут по-прежнему выполняться через REST или gRPC, а события передаваться через Kafka.

Например, запрос текущего баланса удобнее сделать синхронно, а уведомление об изменении баланса — событием.

Kafka и REST API

Kafka не заменяет REST API во всех сценариях.

В современной архитектуре эти технологии часто дополняют друг друга.

Kafka и Webhook

Webhook отправляет HTTP Request внешнему или внутреннему получателю при событии.

Kafka работает как внутренний Event Stream для большого количества Producers и Consumers.

Например, внутреннее PaymentConfirmed проходит через Kafka, а отдельный Consumer отправляет Webhook партнеру.

Kafka и RabbitMQ

Kafka и традиционные Message Brokers часто сравнивают, но выбор зависит от задачи.

Kafka особенно сильна в потоках событий, высокой пропускной способности и повторном чтении истории.

Классический Message Broker может быть удобнее для некоторых очередей задач, маршрутизации и командной модели.

Сравнивать следует конкретные требования, а не только скорость.

Kafka и Redis

Redis может использоваться для простых очередей, Streams и Pub/Sub, но его роль обычно отличается от Kafka.

Redis особенно силен как In-memory Store и Cache, а Kafka — как долговременный распределенный Event Log.

Они могут одновременно присутствовать в одной системе.

Kafka и базы данных

Kafka не является обычной заменой PostgreSQL, MySQL или MongoDB.

Она хранит события в последовательном журнале, но бизнес-приложению часто нужна Database с индексами, транзакциями и запросами текущего состояния.

Kafka и Database обычно выполняют разные роли.

Event Sourcing

Event Sourcing — архитектурный подход, при котором состояние системы восстанавливается из последовательности событий.

Например, баланс может быть результатом применения событий AccountOpened, MoneyDeposited и MoneyWithdrawn.

Kafka может участвовать в такой архитектуре, но наличие Kafka само по себе не означает использование Event Sourcing.

Kafka как Source of Truth

В отдельных системах журнал событий является центральным источником истории.

Однако такое решение требует строгого управления схемами, Retention, восстановлением и семантикой событий.

Для обычного проекта проще использовать Kafka как транспорт событий, сохраняя основное состояние в Database.

Compacted Topic

В некоторых сценариях Kafka может хранить актуальное последнее значение для каждого Key наряду с журнальной моделью.

Такой подход полезен для потоков изменений состояния и восстановления локальных представлений.

Он не превращает Kafka в полноценную универсальную Database, но расширяет возможности Event-driven систем.

Dead Letter Queue

Если Consumer не может обработать определенное сообщение даже после Retry, его полезно перенести в отдельный поток ошибок.

Так основная обработка не блокируется одним Poison Message.

Инженер затем анализирует проблемные события и решает, нужно ли их исправить и повторно обработать.

Poison Message

Poison Message — сообщение, которое стабильно вызывает ошибку Consumer.

Причиной может быть неправильная Schema, некорректные данные или баг приложения.

Бесконечный Retry одного такого события способен остановить обработку Partition.

Retry Topics

Для временных ошибок можно использовать отдельные потоки повторной обработки.

Например, внешний API недоступен, поэтому событие повторяется через несколько минут.

Retry Strategy должна учитывать максимальное количество попыток и не создавать бесконечный цикл.

Backpressure

Backpressure возникает, когда Producers создают события быстрее, чем Consumers успевают их обрабатывать.

В Kafka сообщения продолжают накапливаться в Topic до пределов Retention и инфраструктурных ресурсов.

Так система может временно пережить всплеск, но длительное отставание требует масштабирования или оптимизации Consumers.

Consumer Lag

Consumer Lag показывает, насколько Consumer отстает от последних доступных сообщений.

Это одна из ключевых метрик Kafka.

Если Lag постоянно растет, сервис не успевает обрабатывать входящий поток.

Причины высокого Consumer Lag

• Consumer работает слишком медленно;
• недостаточно экземпляров;
• слишком мало Partitions для параллелизма;
• внешняя база работает медленно;
• появились ошибки и Retry;
• резко вырос поток сообщений.

Throughput

Throughput показывает объем данных или количество сообщений, которые система обрабатывает за единицу времени.

Kafka проектируется для больших последовательных потоков, поэтому особенно эффективна при пакетной и потоковой передаче событий.

Но производительность зависит от размера сообщений, количества Partitions, дисков, сети и настроек Producers и Consumers.

Latency

Latency — время между отправкой события и его доступностью или полной обработкой.

Для одних систем допустимы секунды, для других нужны сотни миллисекунд.

Оптимизировать Kafka следует под реальные SLO, а не просто минимальное возможное время.

Размер сообщения

Kafka обычно лучше работает с относительно небольшими событиями.

Передавать через Kafka огромные видеофайлы или Backup нецелесообразно.

Для больших объектов лучше сохранить файл в Object Storage, а в событии передать ID или ссылку на объект.

Batching

Producer может объединять несколько событий в Batch для более эффективной передачи.

Это уменьшает сетевые накладные расходы и повышает Throughput.

Но ожидание заполнения Batch может немного увеличить latency.

Compression

Потоки сообщений можно сжимать, чтобы уменьшить сетевой трафик и размер хранения.

Платой становится использование CPU на Compression и Decompression.

Выбор следует делать по реальному профилю данных и инфраструктуры.

Kafka и диски

Несмотря на высокую скорость, Kafka не является исключительно In-memory системой.

Основная журнальная модель ориентирована на хранение данных на диске с эффективными последовательными операциями.

Поэтому производительность дисковой подсистемы и объем свободного места являются критичными параметрами.

Kafka и Docker

Kafka можно запускать в Docker для development и тестирования.

Docker Compose позволяет поднять Broker и тестовые приложения локально.

Production Kafka требует значительно более тщательной настройки сети, дисков, Persistent Storage, Replication и мониторинга.

Kafka и Kubernetes

Kafka может работать в Kubernetes, но является Stateful Distributed System.

Необходимо учитывать Persistent Volumes, сетевую идентичность Brokers, обновления и распределение реплик по узлам.

Простой запуск нескольких контейнеров не обеспечивает автоматически надежный Cluster.

Kafka в облаке

Kafka можно администрировать самостоятельно или использовать Managed Kafka Service.

Управляемая модель уменьшает объем работы с Brokers и частью инфраструктуры.

Но команда приложения все равно отвечает за Topics, Schemas, Consumer Groups, Lag и корректность обработки событий.

Kafka и Infrastructure as Code

Настройки Topics, доступов и инфраструктуры можно управлять через IaC и GitOps-подходы.

Это уменьшает количество ручных изменений production.

Конфигурация проходит Review и становится воспроизводимой.

Kafka и CI/CD

Изменения Producers и Consumers должны тестироваться на совместимость событий.

Pipeline может проверять Schema и Integration Tests.

Особенно важно не выпускать Producer, который начинает публиковать формат, несовместимый с работающими Consumers.

Kafka и Observability

Распределенную событийную систему невозможно надежно эксплуатировать без метрик.

Следует отслеживать состояние Brokers, Throughput, Latency, Consumer Lag, ошибки Consumers и использование дисков.

Нужно также видеть полный путь бизнес-события через сервисы.

Основные метрики Kafka

Kafka и Prometheus

Метрики Kafka можно передавать в Prometheus через соответствующие механизмы мониторинга и exporters.

Grafana позволяет строить дашборды Consumer Lag, Throughput, Storage и состояния Brokers.

Alerts особенно важны для растущего Lag и проблем репликации.

Kafka и OpenTelemetry

Distributed Tracing помогает связать событие Kafka с исходным HTTP Request и последующей обработкой Consumers.

Trace Context можно передавать вместе с Metadata сообщения.

Так инженеры видят полный путь заказа через API, Kafka и несколько микросервисов.

Correlation ID

Correlation ID связывает несколько операций одного бизнес-процесса.

Например, Order ID или Trace ID передается через все события.

Это существенно упрощает диагностику распределенной системы.

Логирование Kafka Consumers

Consumer должен логировать ошибки обработки, Event ID и важные технические параметры.

При этом нельзя без необходимости записывать в логи полный Payload с персональными или финансовыми данными.

Лучше использовать структурированное логирование и Trace ID.

Безопасность Kafka

Kafka может передавать критичные данные между внутренними системами, поэтому Cluster необходимо защищать.

• ограничивать сетевой доступ;
• аутентифицировать Producers и Consumers;
• разграничивать права на Topics;
• шифровать соединения;
• защищать Secrets;
• вести аудит административных изменений;
• регулярно обновлять инфраструктуру.

Authorization

Не каждый сервис должен иметь доступ ко всем Topics.

Например, analytics-service может читать orders, но не должен публиковать PaymentConfirmed.

Минимальные права снижают последствия ошибки или компрометации сервиса.

Персональные данные в Kafka

Событие остается в Topic в течение Retention, поэтому персональные данные могут храниться дольше, чем ожидает разработчик.

Не следует отправлять весь объект пользователя, если Consumers нужны только user_id и status.

Минимизация Payload уменьшает риски утечки и упрощает изменение Schema.

Удаление данных из Event Log

Журнальная модель усложняет работу с информацией, которую необходимо удалить из всех сохраненных событий.

Поэтому чувствительные данные лучше передавать по идентификатору, если их необязательно хранить непосредственно в Event Stream.

Требования к Retention необходимо учитывать уже при проектировании.

Kafka и GDPR-подобные требования

Если инфраструктура обрабатывает персональные данные, нужно учитывать сроки хранения, права доступа и возможность удаления информации согласно применимым требованиям.

Конкретная реализация зависит от юрисдикции и политики организации.

Преимущества Apache Kafka

• высокая пропускная способность;
• масштабирование через Partitions;
• хранение истории событий;
• несколько независимых Consumer Groups;
• асинхронная интеграция сервисов;
• Replay событий;
• подходит для Data Pipeline;
• полезна в Event-driven Architecture.

Недостатки Apache Kafka

• сложнее обычного HTTP API;
• требует эксплуатации распределенного Cluster;
• нужно управлять Partitions и Retention;
• Consumers должны учитывать Duplicate;
• сложнее трассировать бизнес-процесс;
• Schema Evolution требует дисциплины;
• не является универсальной заменой Database или обычной очереди.

Типичные ошибки при использовании Kafka

1. Добавлять Kafka в небольшой проект без реальной необходимости.
2. Использовать ее как обычную Database.
3. Не продумывать Message Key.
4. Игнорировать Consumer Lag.
5. Не учитывать повторную доставку событий.
6. Менять Event Schema без совместимости.
7. Хранить огромные Payload.
8. Не создавать Dead Letter Queue для постоянных ошибок.
9. Считать Replication заменой Backup и Disaster Recovery.
10. Не защищать доступ к Topics.

Когда Kafka может быть избыточной

Если приложение состоит из одного Backend и пары простых интеграций, Kafka может добавить ненужную сложность.

Обычный REST API или простая Message Queue иногда решат задачу дешевле и понятнее.

Kafka особенно полезна, когда появляется много Producers и Consumers, большие потоки событий или необходимость хранить и повторно читать историю.

Как внедрять Kafka

Шаг 1. Определить реальные события

Topic должен отражать значимые изменения системы, а не случайные технические вызовы.

Шаг 2. Спроектировать Event Contract

Определите обязательные поля, Event ID, Timestamp и правила версионирования.

Шаг 3. Выбрать Message Key

Нужно найти баланс между порядком и равномерным распределением нагрузки.

Шаг 4. Определить Partitions

Количество должно соответствовать требуемому параллелизму и ожидаемому росту.

Шаг 5. Сделать Consumers идемпотентными

Повторное событие не должно повреждать бизнес-состояние.

Шаг 6. Настроить Retry и DLQ

Временные и постоянные ошибки должны обрабатываться по-разному.

Шаг 7. Добавить Observability

Consumer Lag, Throughput и ошибки должны быть видны до того, как проблема заметит пользователь.

Шаг 8. Провести Failure Testing

Нужно проверить поведение при отказе Broker, Consumer, Database и внешних сервисов.

Практический пример

Интернет-магазин состоит из Order Service, Payment Service, Warehouse Service, Email Service и аналитической платформы.

Пользователь оформляет заказ. Order Service сохраняет заказ в PostgreSQL и через Transactional Outbox публикует OrderCreated в Kafka.

Warehouse Service получает событие и резервирует товар. Email Service отправляет подтверждение. Analytics Service записывает событие в аналитическое хранилище.

Все сервисы используют независимые Consumer Groups.

Message Key равен order_id, поэтому события одного заказа попадают в одну Partition и сохраняют относительный порядок.

Consumers хранят Event ID и не выполняют одну бизнес-операцию дважды при повторной доставке.

При временной недоступности внешнего почтового API Email Service отправляет событие на Retry. После нескольких неудачных попыток сообщение попадает в DLQ.

Prometheus контролирует Consumer Lag, а OpenTelemetry связывает HTTP Request оформления заказа с последующими событиями.

В результате Order Service не зависит напрямую от нескольких внешних систем, а новые Consumers можно подключать к потоку без изменения основного сервиса.

Apache Kafka для бизнеса

Для бизнеса Kafka полезна там, где количество интеграций и поток данных становятся достаточно большими, чтобы прямые связи сервис с сервисом начали мешать развитию.

Она позволяет отделить источник события от его потребителей, подключать новые системы и обрабатывать данные почти в реальном времени.

Например, один поток продаж можно одновременно использовать для CRM, BI, рекомендаций и контроля склада.

Но Kafka добавляет стоимость инфраструктуры и эксплуатации. Необходимо поддерживать Cluster, мониторинг, Schema Contracts и правила обработки ошибок.

Когда стоит использовать Apache Kafka

• много сервисов обмениваются событиями;
• нужен Event-driven подход;
• требуется Replay истории;
• строится Data Pipeline;
• поступает большой поток событий;
• одни данные должны читать несколько независимых систем;
• нужно разделить Producers и Consumers;
• требуется горизонтально масштабировать обработку.

Когда Kafka может не понадобиться

Для простого CRUD-приложения с одной базой и небольшим количеством интеграций Kafka часто будет лишним компонентом.

Также она не нужна только ради отправки одной фоновой задачи, если обычная очередь решает проблему проще.

Технологию стоит внедрять, когда преимущества потоковой архитектуры превышают стоимость ее сопровождения.

Связанные термины

Краткий итог

Apache Kafka — распределенная платформа для передачи и хранения потоков событий. Producers публикуют сообщения в Topics, Topics разделяются на Partitions, а Consumers читают события независимо друг от друга и отслеживают положение через Offsets.

Kafka особенно полезна для Event-driven Architecture, Microservices, Data Pipeline, CDC и потоковой аналитики. Ее журнальная модель позволяет нескольким системам читать один поток и при необходимости повторно обрабатывать историю.

При этом Kafka требует дисциплины: нужно проектировать Event Schema, Message Key, Partitions, Retention, Retry и идемпотентность Consumers. Для production также необходимы мониторинг Consumer Lag, защита доступа, репликация и тестирование отказов. Kafka дает наибольшую пользу тогда, когда системе действительно нужен масштабируемый поток событий, а не просто еще один способ вызвать соседний сервис.