skip to content

Ordering Guarantees

3 roadmaps5 questions

Kafka orders records within a partition and nowhere else, and what that means for keys, in-flight requests, and retries. A classic trap question, since candidates often claim topic-wide ordering.

part ofApache Kafkaoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What ordering guarantee does Kafka provide, and what does it NOT guarantee?

level: juniorimportance: must knowfreq 80%

answer

  1. Order = per-partition only
  2. Partition = append-only log + offsets
  3. No cross-partition order
  4. Partitions = unit of parallelism
  5. Same key for related events

basics

~10 s

Kafka guarantees order only within a single partition: messages are read in the same order they were written. It does NOT guarantee any order across different partitions of a topic.

solid answer

~40 s

Kafka's only ordering guarantee is per-partition total order. Each partition is an append-only log; every record gets a monotonically increasing offset, and a consumer reading that partition sees records strictly in offset order. There is NO ordering guarantee across partitions of the same topic. A topic with N partitions is N independent ordered logs, consumed in parallel, so records in partition 0 and partition 1 can be processed in any interleaving. This means if you need a set of related events ordered relative to each other, they must land in the same partition (typically via a shared message key). Total ordering across a whole topic is only achievable with a single partition, which sacrifices parallelism and throughput.

go deeper

for a junior

Must state: order is per-partition, not per-topic.

for a middle

Should explain partitions as independent logs and the parallelism tradeoff.

for a senior

Connects ordering scope to key routing and repartitioning hazards.

for a principal

Frames ordering vs throughput as a deliberate architectural tradeoff and designs topics accordingly.

## What a partition is A Kafka **topic** is split into one or more **partitions**. Each partition is an *append-only log file*: producers append records to the end, and each appended record is assigned a strictly increasing integer called an **offset** (0, 1, 2, ...). Within one partition, offset order *is* the order of events — it never changes. ## The guarantee Kafka guarantees **per-partition total order**: a consumer reading a partition receives records in ascending offset order, identical to the order the broker wrote them. That is the *entire* ordering contract. ## What is NOT guaranteed There is **no ordering across partitions**. A topic with 6 partitions is effectively 6 independent ordered logs. If record A goes to partition 0 and record B goes to partition 3, Kafka makes no promise about whether A or B is processed first — they are consumed in parallel by potentially different consumer threads/instances. ## Why it's designed this way Partitions are the *unit of parallelism* in Kafka. Throughput scales by adding partitions and consumers. A global total order would require a single serialized log (one partition), which caps throughput at what one broker/consumer can handle. Kafka deliberately trades global order for scalability and lets you opt into ordering only where you need it (per key). ## Practical consequence If two events must be ordered relative to each other (e.g. 'account created' then 'account updated' for the same user), they must be in the *same partition*. The standard way to ensure that is to give them the **same key** (see same-key routing). Events for different keys can safely be reordered because they're independent. ## Edge cases - Single-partition topic = global total order, but no parallelism. - Repartitioning (changing partition count) breaks key→partition stability and can scramble ordering for keys going forward. - Consumer-side parallelism (e.g. a thread pool processing records out of order) can break the guarantee even though Kafka delivered them in order.

  • How do you get a global total order across an entire topic?
    Use a single partition. That serializes all writes into one log but eliminates parallelism, so it only works at low throughput.
  • If two consumers read two different partitions, can you reason about the order of records across them?
    No. They are independent logs consumed in parallel; only the order within each partition is defined.

saying these in an interview costs you the question

  • Saying Kafka guarantees global ordering across a topic
  • Believing topic order is preserved regardless of partition count
  • Thinking adding partitions is free with no ordering impact
  • Confusing offset (per-partition) with a global topic-wide sequence number

context

resolving links…

open as a page

How does message keying preserve per-key ordering, and what is the exact mechanism?

level: middleimportance: must knowfreq 75%

basics

~20 s

Records with the same key are hashed to the same partition by the producer's default partitioner. Since one partition is strictly ordered, all records for a given key are processed in the order they were produced.

open as a page

How can max.in.flight.requests.per.connection cause records to be reordered within a partition, and how does idempotence fix it?

level: seniorimportance: must knowfreq 65%

basics

~10 s

With multiple in-flight batches and retries, a retried earlier batch can land after a later one, reordering within a partition. Enabling the idempotent producer preserves order even with up to 5 in-flight requests.

open as a page

You key correctly and Kafka delivers records in order, yet your consumer still processes events out of order. What consumer-side assumptions break ordering?

level: seniorimportance: should knowfreq 55%

basics

~20 s

Kafka only delivers a partition in order; ordering breaks if the consumer hands records to a thread pool, processes multiple partitions concurrently per record-key, retries/dead-letters async, or commits offsets in a way that lets reprocessing reorder side effects.

open as a page

When is a single-partition topic justified for ordering, and what alternatives give ordering without sacrificing throughput?

level: principalimportance: should knowfreq 40%

basics

~10 s

A single partition gives total topic order but caps throughput to one consumer and one broker. Prefer keyed multi-partition topics so you keep per-entity order while scaling, reserving single-partition for genuinely global-order, low-volume streams.

open as a page