What Is Kafka Used For? 8 Common Use Cases

Apache Kafka is used to move streams of events between systems and keep them in a durable log that many applications can read independently and replay. The common jobs are event streaming between microservices, messaging, website activity tracking, log and metrics aggregation, change data capture (CDC) from databases with Debezium, stream processing, event sourcing, and feeding data lakes, warehouses and AI pipelines. What ties them together is that reading an event does not delete it: retention does, so a new consumer can start from the beginning and a broken one can rewind.

This post is about the jobs. For how Kafka itself is built (brokers, partitions, replication and KRaft controllers), see Kafka architecture. The facts below are for Apache Kafka 4.x; 4.3.0, released on 22 May 2026, is the current feature release, and every 4.x release runs on KRaft only.

What makes a job a good fit for Kafka

Three properties decide whether a job suits Kafka:

A retained log. Events stay for the topic's retention period, seven days by default (retention.ms=604800000), or for good on a compacted topic. Several consumers read the same data at their own pace.
Partitions. A topic is split into partitions that spread load across brokers. Order is guaranteed within a partition, so events with the same key, such as an order ID, stay in order.
Consumer groups. Each group gets the whole stream and tracks its own offsets, so adding a new reader does not touch existing ones. Inside a group, each partition goes to one consumer.

If a job needs those three, Kafka is a strong fit. If it needs per-message routing or delays instead, look elsewhere.

Common Kafka use cases

The Apache Kafka documentation lists messaging, activity tracking, metrics, log aggregation, stream processing, event sourcing and commit logs as its core uses. In practice they look like this:

Use case	How Kafka does it	The catch
Event streaming between microservices	Services publish domain events, such as `order-placed`, to topics; any number of other services subscribe through their own consumer groups.	The topic becomes a shared contract. Agree a schema and a compatibility rule before the second team starts consuming.
Messaging between services	Producers write with `acks=all`; consumers commit offsets after processing. Since Kafka 4.2, share groups (Queues for Kafka) are production-ready and let several consumers share one partition with per-record acknowledgement.	No broker-side routing, priorities or per-message delays. Lag is the health signal to watch; see Kafka consumer lag.
Website activity tracking	Kafka's original use case: page views, searches and clicks published to topics, often one topic per activity type.	Volume is high and keys are skewed. A hot user or page can overload one partition; see Kafka partition strategy.
Log and metrics aggregation	Logs and operational metrics from many hosts are written to topics, then shipped to search, monitoring or storage by consumers or Kafka Connect sink connectors.	Retention must match disk. Tiered storage, production-ready since Kafka 3.9, moves closed segments to object storage; see Kafka retention policy.
Change data capture with Debezium	Debezium source connectors run on Kafka Connect and read the database's own log, such as the MySQL binlog or PostgreSQL logical replication, writing each table's changes to its own topic by default.	On PostgreSQL the replication slot holds WAL until the connector confirms it, so a stopped or lagging connector grows disk use on the database. Schema changes and snapshots need planning; see Debezium support.
Stream processing	Kafka Streams, a Java library, reads topics, joins and aggregates them, and writes results back, with exactly-once processing via `processing.guarantee=exactly_once_v2`. Flink is the common alternative.	State stores are rebuilt from changelog topics after a restart, which can take a long time on large state. See Kafka exactly-once semantics.
Event sourcing and commit logs	State changes are stored as a time-ordered sequence of records; log compaction keeps the latest value for each key so a service can rebuild state from the topic.	Compaction is not instant, and deleting a key needs a tombstone record. Test the rebuild time before relying on it.
Feeding data lakes, warehouses and AI pipelines	Sink connectors land topics in object storage, warehouses and search indexes; the same events can feed embedding pipelines and agent tools.	Every sink is another consumer group with its own failure modes. For agent workloads, see Kafka for AI agents.

A durable starting point

A minimal durable topic for any of the jobs above, using the tools shipped with Kafka 4.x:

bin/kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic orders --partitions 12 --replication-factor 3 \
  --config min.insync.replicas=2 --config retention.ms=604800000

# producer side
acks=all
enable.idempotence=true

Replication factor 3 with min.insync.replicas=2 and acks=all lets one broker be down while writes continue on two copies. Pick the partition count with care: Kafka cannot reduce it later, and adding partitions changes which partition a key maps to.

Where Kafka is the wrong tool

Small task queues that need per-message routing, priorities or delays. Share groups now give Kafka queue-style consumption, but routing and delayed retries are still broker features in RabbitMQ. See RabbitMQ vs Kafka and what RabbitMQ is used for.
Low volume with a small team. A production cluster means brokers, a KRaft controller quorum of three or five, monitoring and upgrades. At a few messages per second the operating cost usually outweighs the benefit.
A database you query. Kafka reads by offset, not by field. Land the data in a database or warehouse and query it there.
Synchronous request-reply. Kafka can carry it, but an HTTP or gRPC call is simpler and faster for most services.

Managed alternatives are compared in Kafka vs Kinesis and NATS vs Kafka.

Running these use cases on Kafka 4.x

Kafka 4.0, released on 18 March 2025, removed ZooKeeper, so clusters still on ZooKeeper must migrate to KRaft on a 3.x release before they can upgrade. Our Kafka end-of-life guide covers version dates and the upgrade path. If that upgrade cannot happen soon, OSSeva provides extended support for Apache Kafka 2.8 to 3.9 while you plan it.

When to get help

Most Kafka trouble starts with a decision made for one of the jobs above: a partition count picked before the key was understood, retention sized to disks rather than to need, a Debezium connector left stopped while WAL piles up, or a cluster used as a queue for work that needed routing. AceMQ provides independent Kafka support for open-source Apache Kafka, with engineers who review clusters against the jobs they actually do and take the call when they misbehave, and Kafka managed services if you would rather hand over day-to-day operations.

Sources

Frequently Asked Questions

What is Kafka used for?

Moving streams of events between systems and keeping them in a durable, replayable log: event streaming between microservices, messaging, website activity tracking, log and metrics aggregation, change data capture with Debezium, stream processing, event sourcing, and feeding data lakes and AI pipelines.

What is Apache Kafka in simple terms?

A distributed, append-only log. Producers write events to topics, Kafka stores them across several servers for a retention period, and any number of consumer applications read them at their own pace, each tracking its own position.

Is Kafka a message queue?

Not in the traditional sense. Kafka keeps events after they are read and splits work by partition. Since Kafka 4.2, share groups (Queues for Kafka) are production-ready and add queue-style consumption with per-record acknowledgement, but there is still no broker-side routing, priority or per-message delay.

Is Kafka a database?

No. Kafka stores data durably and compacted topics keep the latest value per key, but you read by offset, not by query. Most teams land Kafka data in a database or warehouse and query it there.

Does Kafka still need ZooKeeper?

No. Apache Kafka 4.0, released on 18 March 2025, removed ZooKeeper, and every 4.x release runs on KRaft controllers. Clusters still on ZooKeeper must migrate to KRaft on a 3.x release before upgrading to 4.x.

When should you not use Kafka?

For small task queues that need per-message routing, priorities or delays, where RabbitMQ fits better; for low message volumes where the operating cost of a cluster outweighs the benefit; and as a database you query.

Guides, comparisons and research