Apache Kafka
Тема дорожной карты · Backend разработчик
Apache Kafka — распределённая платформа потоковой передачи событий, разработанная для высокопроизводительного, отказоустойчивого и долговечного publish-subscribe обмена сообщениями; она функционирует как центральная нервная система событийно-ориентированных микросервисных архитектур в масштабе. Kafka организует данные в топики, разделённые на партиции по кластеру брокеров, позволяя производителям и потребителям масштабироваться независимо — бэкенд REST API может публиковать миллионы событий в секунду в Kafka, пока нижестоящие сервисы (индексаторы Elasticsearch, аналитические конвейеры, сервисы уведомлений) потребляют в своём темпе без обратного давления на производителя. Apache Kafka гарантирует долговечное хранение сообщений (настраиваемое хранение по времени или размеру) и семантику exactly-once через Kafka Transactions, делая её надёжной основой для паттернов event sourcing и CQRS совместно с базами данных PostgreSQL или Cassandra. Kafka Connect предоставляет готовые коннекторы для приёма данных из MySQL, PostgreSQL и MongoDB через CDC (Change Data Capture) и выгрузки в Elasticsearch или хранилища данных, тогда как Kafka Streams и ksqlDB обеспечивают stateful потоковую обработку без отдельного кластера. В продакшене Apache Kafka работает в Kubernetes через оператор Strimzi с CI/CD-пайплайнами, управляющими конфигурациями топиков как Infrastructure as Code (IaC); лаг потребителей мониторится через Prometheus для инициирования алертов при отставании обработки.
Как это работает
Apache Kafka использует кеши (Redis, Memcached, in-process LRU) чтобы избежать дорогого DB или compute, и очереди (Redis Streams, RabbitMQ, Kafka, SQS) чтобы развязать медленную async-работу от request-пути. Стратегии инвалидации кеша: TTL (истечение по времени), write-through (обновлять кеш на запись), event-driven (инвалидация на связанное изменение), cache-aside (читаем кеш, fallback на БД). Паттерны очередей: work queues, pub/sub, exactly-once vs at-least-once.
Когда применять
Кеш — когда замер показывает повтор дорогого compute; никогда "превентивно". TTL-кеш — для данных с допустимой staleness (5-60 секунд закрывает большинство кейсов). Очереди — когда запрос триггерит работу, не помещающуюся в response window (отправка email, обработка файлов, вызовы third-party): возвращайте 202 Accepted + status URL. Consumers очередей — это сервисы со своим мониторингом + репликами.
Типичные ошибки
Ловушки Apache Kafka: stale-кеш, потому что забыли инвалидировать на связанном пути (знаменитая "две сложные проблемы"); cache stampede, когда ключ протух и N запросов одновременно бьют в БД (stale-while-revalidate или singleflight); at-least-once очереди без идемпотентных consumer (дубль emails/charges); не мониторите lag очереди (тихий backlog растёт, потом взрывается).