~2 msMessage delivery at the network throughput limit

tln/dayThe cluster scales to thousands of brokers and petabytes of data

80%+ F100Share of the world's largest companies using Kafka

7 tln/dayMessage volume in LinkedIn's production Kafka cluster

Integrations

Change one system without rewriting the rest

The integration layer cures four ailments of rigid data exchange: data loss, cascading rework, source overload and inconsistency. ESB, Kafka and n8n solve different problems.

50flows in 6 months — a speed benchmark for an ESB project

48flows in production with a target loosely coupled architecture

16xfaster launch of standard integrations compared to code

ESB

Routing, transformation, guaranteed delivery and low-code support of legacy exchanges.

Kafka

Durable log: an event is stored, re-read, multiple consumers read at their own pace.

n8n

Fast orchestration of a process and AI steps where heavy event streaming isn't needed.

sourcedata contractESB/Kafka/n8nmonitoringconsumers

Related Sections

ESB approach Kafka n8n Integration cases Apache Kafka News

Sources

Enterprise Integration Patterns Martin Fowler: Event-Driven Confluent: Kafka vs ESB

Industry solutions

What you can do with Apache Kafka

All solutions

E-commerce and retail A single order event stream that triggers warehouse reservation, payment, and delivery Order processing: eliminates stock mismatches and manual reconciliation between the storefront, warehouse, and ERPLearn more →Finance and banking Streaming processing of transactions and account events with replay for auditing Real-time operations monitoring and antifraud: millisecond responses instead of batch reconciliationLearn more →Manufacturing and IoT Collecting sensor telemetry into an event log with threshold triggers Equipment monitoring: predictive maintenance instead of reacting after downtime occursLearn more →Logistics and transportation Shipment tracking and status events available to all systems through the bus Supply chain tracking: a single order status without polling adjacent systemsLearn more →Telecom Streaming network and billing events for real-time pricing and alerts Network monitoring and billing: real-time stream processing instead of nightly batchesLearn more →Media and content A user event bus (clicks, views) for personalization Recommendations and behavior analytics: a near-real-time profile instead of delayed exportsLearn more →B2B distribution Event-driven integration of PIM, ERP, and partner storefronts through a single broker Catalog and pricing sync: a change is published once and distributed to all consumersLearn more →Healthcare Event exchange between HIS, laboratories, and the patient portal Patient data coordination: results are available to adjacent systems without direct integrationsLearn more →

Capabilities

Apache Kafka Capabilities

Before: ERP↔CRM↔Warehouse↔Storefront↔Payments↔Analytics - an N×N tangle of direct connectionsEvery change requires updating several integrations at onceA failure in one system cascades through synchronous chainsAfter: all systems publish/read events through the Kafka busThe producer does not know the consumers, and the consumer can withstand a neighbor outageA new consumer (ML, reporting) connects to the stream without changing the sources

Comparison diagram with two panels. Left ('Before: point-to-point') shows 5-6 systems (ERP, CRM, warehouse, storefront, payments, analytics) connected by many crossing straight arrows forming a tangled web (N×N links, each brittle and requiring changes when modified). Right ('After: an event bus on Kafka') shows the same systems, each linked by one arrow to a central horizontal Kafka bus: producers publish events from above, consumers subscribe from below. Labels emphasize: left - coupling, manual synchronization, cascading failures; right - loose coupling, async, fault tolerance, decoupling, and adding new consumers without changing sources.

An event bus instead of point-to-point

One event stream instead of N×N direct integrations: adding a new system does not require touching the others

Loose coupling

Services are changed, replaced, and scaled independently - a release in one system does not break adjacent ones

Asynchronous processing

Peak loads are smoothed by the event buffer: the storefront does not go down when the warehouse or payment system responds slowly

Fault tolerance and replay

Events are stored in a durable log: a failed consumer catches up after recovery without data loss

Horizontal scaling

Rising load is handled by adding brokers and partitions without reworking the architecture

Real-time streams

Data becomes available to adjacent systems in milliseconds - orders, stock, and prices sync almost instantly

A single event log as the source of truth

New consumers (analytics, ML, reporting) connect to the existing stream without loading the source systems

Integration portability

Event contracts and a standard broker let you hand support over to another team or contractor without rewriting anything

Approach

How we implement Apache Kafka

Without modifying the core

We do not fork or patch the Apache Kafka core. Apache Kafka stays on the standard upgradable version, while business logic is moved into separate microservices nearby, so platform updates do not break your customizations.

International Standards, Not Homegrown Hacks

Where a mature international solution exists, we use it instead of inventing our own protocol or platform. Before writing code, we study how the problem is already solved in the industry.

Transferability

The solution is loosely coupled and documented: it can be handed over between teams and contractors without rewriting. You are not tied to us.

AI compatibility

Apache Kafka in the AI stack

Data stream for ML and real-time analytics

A single event log is a ready-made source for feature engineering, streaming scoring, and near-real-time marts without loading production systems.

Event bus for AI agents

Kafka's pub/sub model gives agents a loosely coupled channel for exchanging events: one agent publishes a result, others react without knowing about each other.

Event sourcing for reproducibility

A durable log and replay let you reprocess event history for model retraining and AI decision audits.

Event-triggered pipelines

A new event (order, request, stock change) automatically triggers inference or an agent workflow without polling systems.

News

What's new in Apache Kafka

All news

2026-05-22
Kafka 4.3.0: streams-scala and rebalance.protocols marked deprecated
25 KIPs, 600+ commits since 4.2.0. KIP-1244 deprecates the streams-scala module (removal in 5.0). KIP-1237 deprecates the group.coordinator.rebalance.protocols configuration. KIP-1280 moves MirrorMaker to the unified KIP-877 metrics mechanism; the old MirrorMaker metrics are also deprecated.
2026-02-21
Kafka 3.9.2: the final patch in the 3.x branch; ZooKeeper mode is officially retired
3.9.x is the last branch supporting ZooKeeper mode; there will be no minor 3.10 release. In this patch, KIP-1252 resolved the behavioral differences between ZK and KRaft. Since 4.0, Kafka runs only on KRaft; ZooKeeper was removed after 14 years of support, so companies using ZK mode should plan their migration.
2026-02-17
Kafka 4.2.0: Queues for Kafka production-ready, with unified CLI arguments.
38 KIPs. KIP-932 (share groups/queues) has reached production-ready status. KIP-1147 unified CLI utility arguments (--bootstrap-server, --command-config) instead of the inconsistent legacy flags. KIP-1188 added an Allowlist policy for client configuration overrides in connectors, closing a vulnerability.

Queues and routing have been mature native features of Talend ESB for years; in Kafka, queues (share groups) became production-ready only in 4.2, while previously it offered only the pub/sub log model. Talend ESB →
2025-09-04
Kafka 4.1.0: Queues for Kafka in preview, with a new Streams rebalance protocol.
KIP-932 (Queues for Kafka, share groups) entered preview and is not production-ready. KIP-1071 added the Streams Rebalance Protocol based on the new consumer group protocol (KIP-848), available through early access. KIP-877 gave plugins and connectors a unified metrics registration mechanism.

Point-to-point queues have been a native MuleSoft feature from the start; in Kafka, they are an add-on (share groups) over the pub/sub log model, introduced only in 4.1 and still in preview. MuleSoft →

Blog

Articles about Apache Kafka

All articles

Apache Kafka: an event bus for integration

Apache Kafka and ESB in a Loosely Coupled Architecture: How to Reduce Costs, Guarantee Delivery, and Ensure Data Integrity in the IT Systems of Large Enterprises

Learn more