How to Solve Data Ordering Issues in Apache Kafka

Apache Kafka stores records in partitioned logs where each record receives a sequential offset; records from the same producer that share a key are routed to the same partition, guaranteeing order within that partition but not across multiple partitions.

Using a key example, four messages with keys Costco, Walmart, Target, and Best Buy are sent to a two‑partition topic, resulting in Costco and Walmart records in partition 1 and Target and Best Buy records in partition 2. Adding a third partition triggers a rebalance that moves all Best Buy records to the new partition, demonstrating how partition changes affect key‑based ordering.

Other factors that can cause out‑of‑order delivery include broker or client failures and retry logic. A ProducerRecord contains the target topic, value, and optionally a specific partition and key; the article recommends always specifying a key to avoid random partition assignment.

To enforce ordering during retries, set max.in.flight.requests.per.connection=1; for scenarios where ordering is critical, also set in.flight.requests.per.session=1. These settings guarantee sequential request handling but significantly reduce producer throughput and should be used only when ordering is essential.

Kafka offers three delivery semantics: At‑Once (no delivery or a single batch), At‑Least‑Once (no loss but possible duplicates), and Exactly‑Once (each message delivered exactly once). Exactly‑Once delivery is ideal for preserving order and requires three components: an idempotent producer, cross‑partition transactions, and a transactional consumer.

An idempotent producer adds a producer ID (PID) and sequence ID to each message, enabling the broker to deduplicate retries and ensure each message is written only once.

Cross‑partition transactions rely on a transaction coordinator and a transaction log (introduced in Kafka 0.11) to atomically write messages to multiple partitions and track offsets. The coordinator assigns a transaction ID and manages the transaction lifecycle.

Transactional consumers must set isolation.level=read_committed (the default is read_uncommitted) to read only committed data.

The exact‑once transaction workflow consists of ten steps:

Step 1 – initTransactions() registers a transaction ID with the coordinator.

Step 2 – The coordinator increments the producer ID epoch, rejecting writes from previous instances.

Step 3 – The producer adds a new partition before sending data.

Step 4 – The coordinator stores transaction state in memory and writes it to the transaction log.

Step 5 – The producer sends messages to partitions.

Step 6 – The producer begins committing, triggering the two‑phase commit protocol.

Step 7 – (Phase 1) The coordinator prepares the commit by updating the transaction log.

Step 8 – (Phase 2) The coordinator writes commit markers to the involved topic partitions.

Step 9 – The coordinator marks the transaction as committed.

Step 10 – The transaction completes successfully, achieving exactly‑once delivery.

Additional architecture diagrams illustrate the transaction flow and reinforce how understanding Kafka’s ordering mechanisms and applying these configurations ensures that data and applications remain correctly ordered.