Topic & Partition
A Kafka topic isn't a queue — it's a log you only ever append to. The topic is split into partitions, each record is appended to the end of one, and the position it lands in becomes its offset. Multiple partitions mean parallel writes and reads, but ordering is only guaranteed inside a single partition. That's exactly why records sharing a key always land in the same one.
01Topic & Partition
Concept at a GlanceUser actions from a shopping site are sent into Kafka. The receiving side is three lanes — each lane is what Kafka calls a partition.
user-42 just signed in. Which lane the event goes to is decided by hashing the user id (the key) — this one lands on lane 0.
The event is appended to the end of the lane. Nothing existing is edited and nothing is inserted in the middle, which makes writes very fast.
A different user goes to a different lane. user-7's item view stacks up on lane 1, running alongside lane 0.
user-42 added to cart. Same user, so the hash is the same — it must go to lane 0 again.
This is the key point. One user's actions always stack up in the same lane in order, so sign-in → add-to-cart can never flip around.
user-91's search goes to lane 2. With several lanes, three users' events pile up at once — and you can take in that much more.
user-42's checkout lands on lane 0 too. Read this one lane and it's always sign-in → add-to-cart → checkout, whenever you look.
But the guarantee holds only inside a lane. Whether lane 1's sign-out happened before lane 0's checkout, this picture can't tell you.
So the number of lanes trades throughput against ordering. Group whatever must stay in order under the same key, and add lanes everywhere else.
02 Understand It Simply
For EveryoneA topic is not a queue but an append-only log, split across several partitions. Ordering holds inside a partition, not across the topic, so anything that must stay in order is keyed to land in the same partition.
Records are only appended to the end of a partition, never modified in place, which turns writes into sequential disk access and makes them fast.
Partition assignment comes from hashing the key; with no key, records are spread round-robin.
Adding partitions buys parallelism at the cost of any global ordering across the topic.
Consuming doesn't remove anything either — records stay for the retention period, so several consumers read the same data independently.
- –Designing event-streaming pipelines
- –trading partition count against ordering guarantees
- –and using keys to group whatever must stay in order
03 Frequently Asked Questions
FAQWhat is Topic & Partition?+
A Kafka topic isn't a queue — it's a log you only ever append to. The topic is split into partitions, each record is appended to the end of one, and the position it lands in becomes its offset. Multiple partitions mean parallel writes and reads, but ordering is only guaranteed inside a single partition. That's exactly why records sharing a key always land in the same one.
Where is Topic & Partition used?+
Designing event-streaming pipelines, trading partition count against ordering guarantees, and using keys to group whatever must stay in order.
What's a simple analogy for Topic & Partition?+
A topic is not a queue but an append-only log, split across several partitions. Ordering holds inside a partition, not across the topic, so anything that must stay in order is keyed to land in the same partition.