Гарантированная доставка и хранение данных в Apache Kafka: внутренняя механика

Оглавление

1. Введение
2. Гарантии записи и подтверждения доставки сообщений (commit/ack)
3. Архитектура хранения данных в Kafka: партиции, сегменты, индексы
4. Kafka в распределённых системах: репликация, отказоустойчивость и масштабирование
5. Заключение

Введение

Apache Kafka давно стал стандартом для построения масштабируемых событийных платформ и систем потоковой обработки данных. О Kafka написано множество статей и руководств, в которых пошагово разбираются базовые сценарии: как поднять брокер, создать топик, написать “Hello, World” на продюсере и консюмере. Но за пределами этих простых примеров скрывается настоящая сила Kafka – её архитектура хранения данных и уникальные гарантии доставки сообщений даже в условиях сбоев оборудования и масштабирования кластера.

Большинство материалов на ограничиваются темами настройки и базовых интеграций. При этом далеко не всегда подробно объясняется, что на самом деле происходит “под капотом” при записи и подтверждении сообщений, как устроены внутренние механизмы хранения данных, почему Kafka считается надёжной даже при отключённом fsync, и как обеспечивается целостность информации в реальных распределённых системах.

В этой статье мы глубоко разберём ключевые аспекты Kafka, которые отличают её от большинства брокеров сообщений:

• Как достигается гарантия коммита сообщения только после надёжного сохранения;
• Как устроено физическое хранение данных в Kafka – партиции, сегменты, индексные файлы;
• Почему подход Kafka к хранению и репликации идеально подходит для построения надёжных, отказоустойчивых и масштабируемых распределённых систем.

Гарантии записи и подтверждения доставки сообщений (commit/ack)

Apache Kafka изначально спроектирован как распределённый журнал commit-log, обеспечивающий высокую надежность доставки сообщений. Ключевой принцип – сообщение считается коммитнутым (committed) и готовым к потреблению, только когда оно надёжно зафиксировано в кластере. Ниже рассмотрены механизмы, гарантирующие такую фиксацию после записи сообщения в файловую систему Kafka:

• Append-only лог и запись на диск: Продюсер отправляет сообщение лидеру партиции, и брокер сразу добавляет запись в файл логов на файловой системе (операция append). В Kafka данные немедленно пишутся в файловую систему (в системный page cache) без принудительного fsync на диск для каждого сообщения. Это означает, что сообщение быстро попадает в устойчивое хранилище (журнал) на узле-лидере, хотя физически может временно находиться в памяти ОС. Такой подход опирается на возможности ОС по эффективному кешированию диска и обеспечивает высокую производительность последовательной записи.
• Роли fsync и flush: По умолчанию Kafka не выполняет синхронный fsync при каждом сообщении (т.е. не ожидает фактической записи на физический диск перед подтверждением). Вместо этого Kafka полагается на фоновые механизмы ОС, которые самостоятельно сбрасывают данные с кеша на диск, и на репликацию данных между узлами для надёжности. Параметры брокера log.flush.interval.messages и log.flush.interval.ms позволяют настроить периодический fsync (например, flush каждое N сообщений или каждые M миллисекунд), но по умолчанию они установлены в очень большие значения (фактически отключены). Такой выбор сделан сознательно: считается, что лучше доверить ОС управлять записью на диск, избегая двойного кеширования и получая выгоду от агрессивного дискового кеша ОС. Kafka рекомендует полагаться на репликацию для долговечности, а не на синхронный fsync для каждого сообщения.
• Acknowledgments (acks) со стороны продюсера: Механизм подтверждений со стороны брокера позволяет балансировать между задержкой и надёжностью. Продюсер в конфигурации задаёт параметр acks:
  • acks=0 – продюсер не ждет подтверждения от брокера вовсе. Сообщение считается отправленным сразу, но риск потери максимальный (никакого подтверждения записи нет).
  • acks=1 – брокер-лидер подтверждает запись продюсеру после того, как сообщение записано в его локальный лог (дисковый кеш ОС). Репликация к моменту подтверждения может ещё не завершиться. Это быстрее, но если лидер упадёт до репликации, сообщение может потеряться, хотя продюсер получил ack.
  • acks=all (или -1) – продюсер получит подтверждение только когда все инсинхронные реплики (ISR) зафиксировали сообщение в своих логах. Фактически, требуется запись сообщения на лидер и на все реплики, находящиеся в синхронизации. Это обеспечивает наивысшую надёжность: сообщение считается коммитнутым, когда все реплики применили его в свой журнал. Только после этого брокер-лидер шлет подтверждение продюсеру.
• “Committed” сообщение: В контексте Kafka термин “коммитнутое сообщение” означает, что оно успешно записано на все инсинхронные реплики партиции. Благодаря этому консумеры получают только коммитнутые сообщения, и никогда не увидят сообщение, которое впоследствии потеряется из-за сбоя лидера. Эта модель гарантирует, что при отказе лидера ни одно подтверждённое (коммитнутое) сообщение не пропадёт, если хотя бы одна копия данных уцелела на другом брокере.
• Взаимодействие продюсера с брокером: Продюсер отправляет батч сообщений лидеру соответствующей партиции. Лидер пишет их в свой лог и, в случае acks=all, распараллеливает отправку на реплики. Как только все необходимые реплики подтвердили приём (или сразу после записи на лидер для acks=1), лидер отсылает продюсеру ACK. В случае недостижения реплик (например, реплик меньше чем min.insync.replicas), лидер не будет выдавать сообщения консумерам и при acks=all не подтвердит продюсеру, чтобы обеспечить прочность данных.

Рис. 1: Схема подтверждения записи сообщения. В последовательности: (1) продюсер посылает сообщение лидеру; (2) лидер записывает сообщение и реплицирует его на фолловеры; (3) после записи на всех in-sync репликах лидер отправляет продюсеру ACK; (4) консумер читает только подтверждённые (committed) сообщения с лидера.

• Прочность при сбоях: Даже при отключенном fsync Kafka остаётся надёжной за счёт протокола репликации с механизмом восстановления данных. Если брокер неожиданно прекращает работу (аварийно), при перезапуске он может потерять последние несброшенные на диск записи. Однако Kafka спроектирована так, что лог не является единым источником истины для выборов лидера – метаданные хранятся во внешнем координаторе (ZooKeeper или в контроллере KRaft). Поэтому, если один узел потерял последние записи, кластер не “забывает” о них глобально. После перезапуска брокер автоматически восстановит недостающие сообщения с другого репликатора (лидера или новой копии) посредством процессa ISR-восстановления. Лидер хранит смещение последнего подтверждённого сообщения (High Watermark); вернувшийся брокер догоняет журнал до актуального смещения, вновь становясь инсинхронным репликатором. Благодаря этому Kafka может безопасно работать с асинхронной записью без fsync – при падении одного узла его несинхронизированные данные просто восстановятся с других копий.

Важно отметить, что при экстремальном сценарии одновременного сбоя всех узлов кластера (например, одновременное отключение питания), данные, не успевшие сброситься на диск на всех репликах, могут быть утеряны. Это редкий кейс, однако для критичных систем можно снизить риск, распределяя реплики по разным стойкам/ЦОД (избегая общего сбоя питания). Альтернативно – настроить более частый flush на диск ценой производительности. По умолчанию же Kafka делает ставку на репликацию и технические допущения реального мира, предоставляя высокую производительность записи при гарантии, что подтверждённое сообщение не потеряется при падении менее чем всего кластера сразу.

---

---

Архитектура хранения данных в Kafka: партиции, сегменты, индексы

Каждая тема (topic) в Kafka разбивается на несколько партиций – независимых логов, распределённых по брокерам. Партиция – это упорядоченный неизменяемый журнал (append-only log), в который сообщения добавляются последовательно в порядке поступления. Внутри партиции сообщения идентифицируются смещениями (offset), присваиваемыми в порядке добавления. Данные хранятся на диске, но благодаря последовательному характеру записи и чтения достигается высокая эффективность (линейный проход диска гораздо быстрее случайных операций).

Рис. 2: Контейнерная (уровень С4) схема устройства памяти в Apache Kafka.

Структура партиции на диске: Чтобы партиции потенциально содержали огромные объёмы данных без потери производительности, Kafka делит лог каждой партиции на сегменты:

• Сегмент – это файл на диске, содержащий непрерывную последовательность сообщений партиции. У каждой партиции есть несколько сегментов, каждый охватывает диапазон смещений. Например, сегмент0 хранит сообщения с offset 0–934, сегмент1 – 935–1567 и т.д.. Новый сегмент начинает писаться либо когда предыдущий достиг максимального размера (log.segment.bytes, по умолчанию ~1 ГБ) либо по истечении определённого времени (log.segment.ms, по умолчанию 7 дней). Всегда существует один активный сегмент – последний, в который сейчас идёт запись; остальные сегменты “запечатаны” и не изменяются.
• Иммутабельность и последовательность: Сегменты в партиции никогда не изменяются после закрытия – Kafka не перезаписывает и не удаляет отдельные записи в середине журнала. Вместо этого применяется политика удаления целых сегментов по времени/объёму (retention) или очистки (compaction), что описано ниже. Такой append-only подход упрощает консистентность и позволяет параллельное чтение и запись без блокировок: продюсеры только добавляют данные в конец активного сегмента, а консумеры могут читать в своем темпе, даже если продюсер ушёл далеко вперёд.
• Индексные файлы: Для ускорения доступа к данным в середине журнала Kafka создает сопутствующие индексы для каждого сегмента. В каталоге партиции на диске хранятся файлы:
  • .index – индекс смещения в байтовое смещение файла. Он позволяет по нужному offset быстро найти позицию в сегменте (с помощью двоичного поиска по memory-mapped индексу). Проще говоря, если консумер запрашивает чтение с offset X, Kafka по .index находит, с какого байта в .log файле начинается ближайший меньший или равный записанный offset, и читает с этого места.
  • .timeindex – индекс по меткам времени, позволяющий найти смещение, соответствующее заданному timestamp (используется для функций поиска по времени, например, отдать сообщения не старше T).
  • leader-epoch-checkpoint – файл с метаданными эпох лидерства для данной партиции (фиксирует какие брокеры когда были лидерами, для целей исправления разрывов при смене лидера).
  • .log – собственно файл сегмента с данными (например, 00000000000000000000.log для первого сегмента).
  • .snapshot – файл-снимок состояния продюсеров для транзакционных тем (только для активного сегмента, помогает при лидерстве сохранить идемпотентность, не углубляясь тут).

В результате структура каталога партиции выглядит примерно так (пример для test-topic-0 с двумя сегментами):

test-topic-0/
 |-- 00000000000000000000.log
 |-- 00000000000000000000.index
 |-- 00000000000000000000.timeindex
 |-- 00000000000000001007.log
 |-- 00000000000000001007.index
 |-- 00000000000000001007.timeindex
 |-- 00000000000000001007.snapshot
 |-- leader-epoch-checkpoint

Каждый сегмент имеет свой парный .index и .timeindex. Индексы загружаются в память через mmap, поэтому поиск по смещению происходит практически мгновенно, не читая весь файл журнала.

Политика ротации и удаления сегментов (retention): Kafka не хранит сообщения вечно по умолчанию. Политика хранения задаётся на уровне топика (или кластера) и может быть основана на времени или размере:

• При использовании политики удаления (delete) Kafka будет удалять старые сегменты, выходящие за рамки периода хранения или превышающие лимит объёма. По умолчанию log.retention.hours=168, то есть сообщения хранятся 7 дней. Можно задать retention.bytes для ограничения общего объёма логов топика – тогда при превышении размера будут удаляться самые старые сегменты. Удаление происходит сегментами: как только весь сегмент старше порога, он удаляется целиком.
• Политика компактации (compact) действует иначе: Kafka будет очищать лог, оставляя только последнюю запись для каждого ключа сообщения. Эта политика полезна для хранения актуального состояния (последних значений) при использовании Kafka как хранилища событий (event sourcing, CDC). Компактация происходит в фоне: проходит по старым сегментам и выбрасывает устаревшие записи, для которых в более новых сегментах есть запись с таким же ключом. В итоге в логе остаётся хотя бы одна – самая свежая – запись на ключ. Можно комбинировать compact+delete (например, сначала компактировать ключи, а затем удалять по времени самые старые сегменты).

По умолчанию для обычных топиков включена политика удаления через 7 дней, что покрывает многие сценарии (неделя исторических данных). Это означает, что даже прочитанные консумером данные некоторое время доступны в Kafka – потребители могут перечитывать недавние события, новые потребители могут догонять историю, а при временной недоступности потребителя данные не потеряются, пока укладываются в retention-период. В отличие от традиционных очередей, где сообщения удаляются сразу после чтения, Kafka разделяет понятие хранения и подтверждения потребления. Сообщения остаются в журнале, а положение потребителя (offset) сдвигается по мере чтения. Таким образом, разные потребители (группы) могут читать один и тот же топик независимо, каждый со своей позицией.

Оптимизация дискового доступа: Благодаря сегментации и использованию page cache ОС Kafka достигает близкого к O(1) времени доступа независимо от размера данных. Последовательные операции чтения/записи крайне эффективны: современный диск может обрабатывать сотни МБ/с последовательных данных vs. всего сотни KB/с при случайном доступе. Kafka максимально использует эту разницу, всегда читая/пишуя последовательно и доверяя ОС кешировать файлы. Все свободное ОЗУ серверов фактически служит кешем для логов Kafka автоматически (страницы файлов в памяти), что удваивает эффективность (данные хранятся в компактном бинарном виде, без накладных расходов Java-объектов). Интересно, что при тёплом page cache чтение из диска порой может быть быстрее прямого доступа к оперативной памяти, за счёт оптимизаций предвыборки и группировки операций ввода-вывода. Поэтому Kafka не пытается дублировать кеш на уровне приложения – вся логика кэширования отдаётся операционной системе. Это существенно упрощает дизайн брокера и снижает нагрузку на сборщик мусора JVM (так как большая часть данных лежит вне heap, в page cache).

Наконец, стоит упомянуть, что Kafka не блокирует запись старыми потребителями: консумер читает из середины журнала – эти данные могут уже быть удалены по политике хранения. Чтобы избежать попытки чтения удалённых данных, Kafka отслеживает для каждой потребительской группы смещение начала (Log Start Offset) – минимальный offset, ещё доступный в логе. Если потребитель отстаёт настолько, что его offset < startOffset (т.е. сегмент уже удалён), при попытке чтения он получит специальную ошибку (обычно OffsetOutOfRange), и должен заново начать с актуального начала лога (или другого установленного позиции). При корректных настройках retention, Kafka обеспечивает хранение сообщений достаточное время, чтобы потребители успевали их обработать, а также позволяет построить повторное чтение и time-travel по журналу (например, пересчитать события за вчера).

Kafka в распределённых системах: репликация, отказоустойчивость и масштабирование

Kafka крайне широко применяется как основа event-driver и стриминговых систем благодаря своей способности масштабироваться и переживать сбои без потери данных. Рассмотрим, как архитектура Kafka обеспечивает эти свойства, и как она используется в современных микросервисах, event sourcing и Big Data:

Репликация и отказоустойчивость кластера: Каждый топик в Kafka может быть сконфигурирован с фактором репликации N – это значит, что каждая партиция этого топика будет храниться на N разных брокерах (1 лидер + N-1 реплик-фолловеров). В нормальном режиме одна копия является лидером – к ней пишут продюсеры и с неё читают консумеры, остальные копии – фолловеры, которые пассивно повторяют журнал лидера. Фолловеры постоянно фетчат (запрашивают) новые записи у лидера и добавляют к себе в лог, стараясь не отставать более заданного порога (replica.lag.time.max.ms и др.). Множество реплик, которые актуальны (не сильно отстали), называется In-Sync Replicas (ISR). Поддерживается правило, что лидером может стать только реплика из ISR, т.е. полностью синхронизированная. Это гарантирует, что новая роль лидера всегда переходит к узлу, у которого есть все зафиксированные сообщения.

Когда лидер выходит из строя (внезапно падает или теряет связь), Kafka автоматически проводит выбор нового лидера среди ISR для каждой затронутой партиции. Этот процесс координируется централизованным контроллером (ранее – ZooKeeper, в новых версиях – встроенный Quorum Controller). Новый лидер продолжает обслуживание клиентов. Благодаря репликации Kafka может пережить до N-1 одновременных падений брокеров (при факторе N) без потери данных. Коммитнутое сообщение не будет утрачено, пока жив хотя бы один брокер с этой партицией. Даже в случае отказа лидера сразу после подтверждения записи (ACK), копия на реплике послужит источником истины – новый лидер уже содержит это сообщение и не потеряет его. Таким образом, Kafka обеспечивает безопасность данных в сценарии “fail-stop” узлов – при обычных сбоях/перезапусках данные сохраняются за счёт дублирования на других узлах.

Рис. 3: Архитектура кластера Apache Kafka (продюсер, брокеры, консюмер, ZooKeeper/Controller)

Если же произошло разделение сети (сетевой partition), ситуация сложнее – Kafka предпочитает сохранить консистентность данных ценой временной недоступности части системы (требуется кворум ISR для продолжения работы). Обычно кластер не будет позволять изолированному брокеру стать лидером, если он не в ISR (на случай split-brain). Администратор может включить “unclean leader election” в экстренных случаях, но это чревато потерей сообщений, поэтому опция отключена по умолчанию.

Масштабирование и производительность: Kafka достигает горизонтального масштабирования за счёт партиционирования данных и распределения партиций по разным брокерам. Топик с большим числом партиций может параллельно обрабатываться множеством узлов, увеличивая пропускную способность системы практически линейно с добавлением новых брокеров. Консумерские группы также масштабируются – несколько консумеров в группе разделяют партиции между собой, обрабатывая сообщения параллельно. Kafka гарантирует, что каждая партиция одновременно обрабатывается только одним консумером в группе, сохраняя порядок внутри партиции, но позволяя различным партициям читаться параллельно разными экземплярами сервиса. Благодаря этому при добавлении партиций и узлов можно достичь практически неограниченного throughput (известны развертывания Kafka, обрабатывающие миллионы сообщений в секунду). Производительность Kafka масштабируется от небольших нагрузок до больших данных – “от малого до большого” – без архитектурных изменений, достаточно добавить железо и разделить топики на больше партиций.

Kafka спроектирована как слабо связанную систему, где брокеры выполняют минимальные функции (не трансформируют сообщения, а только хранят и передают). За счёт этого добавление новых брокеров не приводит к перераспределению вычислительной нагрузки, а только распределяет I/O. Репликация и клиентские протоколы работают асинхронно, что обеспечивает низкие задержки даже под высокой нагрузкой.

Рис. 3: Контейнерная (уровень С4) схема архитектуры Kafka. Показаны продюсер и консюмер сервисы, взаимодействующие с кластером Kafka из нескольких брокеров. Данные публикуются продюсером в топик (партицию) на лидере Broker 1, который реплицирует записи на Broker 2 и 3. Координационный сервис (ZooKeeper/контроллер) управляет метаданными кластера и выбором лидеров (пунктиром). После подтверждения записи на репликах лидер отправляет ACK продюсеру. Консюмер читает сообщения с брокера-лидера (только подтверждённые сообщения доступны консюмерам).

Использование в микросервисной архитектуре: Благодаря описанным свойствам, Kafka стала де-факто стандартом для асинхронного взаимодействия микросервисов. В event-driven микросервисной архитектуре отдельные сервисы публикуют события о произошедших изменениях в топики Kafka, а другие сервисы их потребляют и реагируют. Эта шина событий позволяет избавиться от жёсткой связности: сервисы не вызывают напрямую друг друга, а общаются через общий лог событий. В результате повышается устойчивость системы к частичным сбоям – если какой-то сервис временно недоступен, события накапливаются в Kafka (благодаря надёжному хранению сообщений), и потребитель сможет обработать их позже, не потеряв данные. Кроме того, облегчается масштабирование: можно запустить несколько экземпляров потребителя, которые образуют группу и параллельно обрабатывают разные партиции (Kafka сама сбалансирует нагрузку). Kafka реплицирует события на несколько узлов, обеспечивая сохранность данных даже при падении одного из сервисов или брокеров, так что ни одно событие не пропадёт. В совокупности это делает систему из микросервисов более реактивной, масштабируемой и отказоустойчивой.

Event Sourcing и Kafka: В паттерне event sourcing состояние системы сохраняется не в виде текущих значений, а как журнал событий, из которого это состояние может быть восстановлено. Kafka идеально подходит на роль такого журнала, поскольку она сама является распределённым хранением последовательности неизменяемых событий. Сочетание долговечного хранения событий + возможность репликации и масштабирования делает Kafka естественным выбором для event sourcing систем. Например, в финансовом приложении можно хранить в Kafka все события транзакций (депозиты, снятия) для счетов. Текущее сальдо не хранится напрямую, а вычисляется суммированием событий. Kafka обеспечивает, что эти события не теряются и доступны для пересчёта – можно в любой момент реплейнуть (перечитать) весь поток для восстановления состояния счета, что ценно для аудита и отладки. Более того, Kafka гарантирует порядок событий внутри партиции (обычно партицию выбирают по аггрегату, например, все события одного банковского счёта идут в одну партицию по ключу счета), что критично для корректной реконструкции состояния (события применяются в порядке). Многие системы используют Kafka + лог-компактацию для хранения последних состояний сущностей: Kafka периодически очищает старые события, оставляя только финальное состояние по ключу – получается материальное представление текущего состояния, но с сохранением истории изменений (в компактированном виде). В общем, Kafka предоставляет масштабируемый, отказоустойчивый и упорядоченный журнал событий – фундамент для event sourcing в распределённых приложениях.

Обработка больших данных и стриминг: В экосистеме больших данных Kafka часто служит “трубопроводом” для потоковой передачи данных между системами. Она интегрируется с Flink, Spark, Hadoop и другими, позволяя надёжно буферизировать и транспортировать миллионы событий (например, клики, метрики, логи) в реальном времени. С помощью Kafka Connect можно связывать Kafka с хранилищами данных, БД, системами очередей, строя масштабируемые конвейеры ETL. Инструменты типа Kafka Streams или ksqlDB дают возможность прямо на лету, внутри Kafka, выполнять преобразования и агрегаты над сообщениями. Таким образом, Kafka не только транспорт, но и платформа для stream processing.

Kafka показывает себя отлично в сценариях реального времени, где требуется минимальная задержка от поступления события до реакции. Благодаря высокой пропускной способности и низким оверхедам на брокерах, задержки в Kafka измеряются миллисекундами, что позволяет строить онлайн-аналитику, мониторинг и системы реагирования на события. Например, Kafka используется для отслеживания IoT-датчиков: устройства публикуют тысячи событий в секунду (телеметрия), Kafka распределяет их по разделённым партициям, а потребители (например, система аномалий или дашборды) параллельно обрабатывают поток. За счёт линейной масштабируемости можно нарастить кластер для любых объёмов данных – известны кейсы, где Kafka устойчиво работает с гигабайтами в секунду входящих данных.

Подводя итог, Apache Kafka предоставляет надёжный фундамент для распределённых систем обработки событий. Механизмы подтверждения (ack) и репликации обеспечивают гарантированную доставку сообщений даже при сбоях узлов, архитектура append-only логов на диске – высокую производительность и долговременное хранение, а партиционирование – горизонтальное масштабирование под большие нагрузки. Эта комбинация делает Kafka универсальным решением для очередей сообщений, журнала событий и стриминговой платформы в современных микросервисных, облачных и Big Data системах. Благодаря Kafka компании строят гибкие и устойчивые архитектуры, где данные воспринимаются и обрабатываются как непрерывные потоки событий, надежно и масштабируемо проходящие через центрлизованный общий лог. Это меняет подход к интеграции систем – от периодических пакетных загрузок к потоковой, событийно-ориентированной архитектуре в реальном времени.

Заключение

Архитектура хранения и механизм гарантированной доставки сообщений – это то, что превращает Kafka из “обычного брокера сообщений” в мощную платформу для построения надёжных, масштабируемых и отказоустойчивых распределённых систем. Мы разобрали, как Kafka достигает высокой прочности даже при огромных объёмах данных и высоких нагрузках: за счёт использования append-only логов, сегментации, гибкой политики хранения, а также благодаря продуманной репликации между брокерами и строгому протоколу подтверждения доставки.

Глубокое понимание того, как работают подтверждения записи (ack), зачем нужны in-sync реплики, что происходит при сбоях и почему консюмеры читают только коммитнутые данные – позволяет не только правильно эксплуатировать Kafka, но и проектировать системы, которые устойчивы к реальным сбоям, не теряют важные события и способны масштабироваться без архитектурных изломов.

Практическое применение этих принципов – фундамент современных микросервисных платформ, event sourcing, обработки IoT-потоков, потоковой аналитики и интеграционных шин. Используйте возможности Kafka осознанно: балансируйте между производительностью и надёжностью через параметры ack, фактор репликации и retention, проектируйте топики и партиции под реальные бизнес-потоки, а главное – учитывайте нюансы архитектуры хранения и доставки при построении своих сервисов.

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