Acknowledgements and Message Ordering

1What an Acknowledgement Means

An ack is the consumer telling the broker "I'm done with this message — don't give it to anyone again." Until a message is acked, the broker considers it in flight and will redeliver it if the consumer disconnects or the visibility timeout expires.

Kafka's ack is cumulative: committing offset 105 acknowledges 0–104. RabbitMQ and SQS acks are individual. That difference shapes how you handle failures and ordering.

2When to Ack

• After the side effect is durably done (DB committed, email provider accepted) — at-least-once.
• Never "ack early to free the broker" for messages you can't afford to lose.
• Long-running work: extend the lease (SQS ChangeMessageVisibility, RabbitMQ has no timeout by default but has a consumer_timeout), or the message is redelivered while you're still working on it.

3Ordering Guarantees Are Narrow

Brokers only guarantee ordering within a single queue or partition, and only for a single consumer processing sequentially:

• Kafka: ordered within a partition. Use the entity id as the key (orderId) so all of one entity's events share a partition.
• RabbitMQ: FIFO per queue — but with multiple consumers or prefetch > 1 with requeues, processing order breaks.
• SQS standard: best-effort ordering only. SQS FIFO: ordered per MessageGroupId.

You almost never need global order. You need order per entity ("OrderCancelled must not be applied before OrderCreated for the same order").

4How Ordering Breaks in Practice

5Keeping Order While Scaling

• Partition by key, process each key serially: inside one consumer you can run many keys in parallel as long as each key's messages are processed one at a time (a per-key queue / "keyed executor").
• SQS FIFO message groups / RabbitMQ consistent-hash exchange: the same idea in other brokers.
• Make handlers order-tolerant where possible:
  • carry a version / sequence number in each event; ignore events older than what you've stored (UPDATE ... WHERE version < :v)
  • use commutative updates (increment counters, add to sets) rather than "set to"
  • buffer out-of-order events briefly until the gap is filled (with a timeout)

UPDATE orders SET status = :status WHERE id = :id;
-- 'paid' (v2) arrives after 'shipped' (v3) → order shows 'paid'

UPDATE orders SET status = :status, version = :v
 WHERE id = :id AND version < :v;
-- the stale 'paid' (v2) updates 0 rows and is ignored

6Retries Without Blocking (Kafka)

Because Kafka acks are cumulative, a failing message at offset 105 blocks commits for 106+ in that partition. Options:

1. retry in place a few times (blocks the partition — fine for brief glitches)
2. publish the failed message to a retry topic (orders.retry.1m, orders.retry.10m) and commit — unblocks the partition but gives up strict per-key ordering for that key unless you also park subsequent messages of the same key
3. after N attempts, dead-letter it (10-dead_letter_queues/)

Under the HoodWhy Cumulative Acks Make Kafka Fast — and Rigid▾

A Kafka consumer's entire acknowledgement state is one integer per partition. The broker doesn't track which individual records were processed; it doesn't need per-message locks, redelivery flags or timers. That's a big part of why Kafka can serve millions of messages per second with tiny broker overhead.

The rigidity follows directly: you can't say "105 failed but 106–110 succeeded" — committing 111 acknowledges 105 too. If you process records in parallel and commit, you must commit only up to the lowest contiguous completed offset (a "commit watermark"), or a crash can skip unfinished records. RabbitMQ and SQS track each delivery individually (a delivery tag / receipt handle per message), which allows fine-grained nack/requeue and per-message timeouts — at the cost of more broker-side state per message.

⚠️ Common Pitfalls

1. Acking before the work is durable → silent loss.
2. Assuming the broker gives global order → bugs once you scale consumers.
3. Requeue-on-failure in a FIFO queue → reorders messages for that entity and can loop forever on a poison message.
4. Committing the highest finished offset with parallel processing → skipped records after a crash.
5. Keying related events differently → they land on different partitions.
6. No version checks in handlers that "set" state → older events overwrite newer state.

📋 Quick Reference

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: broker_acknowledgements_and_message_ordering_theory.md · generated by tools/build_lessons.py