Knowing what Kafka is (and is not) tells you when an event log beats a queue, a database or direct API calls.
Apache Kafka stores events (also called records or messages): small facts such as "order 17 was paid" or "sensor 4 read 21.5". Producers append events to named topics; consumers read them. Three properties make Kafka different from a classic message queue:
- Durable log: events are written to disk and kept for a configured retention (days, forever, or until size limits), not deleted when read.
- Independent readers: any number of consumer applications read the same topic at their own pace, each tracking its own position. Adding a new consumer does not affect producers or other consumers, and a consumer can replay history.
- Scale: topics are split into partitions spread over a cluster of brokers, so throughput grows to millions of events per second.
Typical uses: decoupling microservices with events, data pipelines into warehouses and lakes, change data capture from databases, activity tracking, log aggregation, and real-time stream processing.
Kafka is not a database for ad-hoc queries, and not ideal for per-message work queues with individual acknowledgements and delays (although newer share groups add queue-like consumption). It also adds operational weight: for a few messages between two services, a simple queue may be enough.
The ecosystem includes Kafka Connect for integrations and Kafka Streams for processing, both part of Apache Kafka.
Remember
- Kafka is a durable, partitioned, replicated log of events
- Reading does not delete: many consumers read independently and can replay
- Used for event-driven services, pipelines, CDC and stream processing
Watch out for
- Treating Kafka as a request/response channel between two services instead of an event log.