Queues, Duplicate Delivery, And Ordering
Most practical queues provide at-least-once delivery under some failures, so handlers must expect duplicate and reordered messages.
Why This Matters
Acknowledgement, visibility timeout, retries, dead letters, and partition ordering shape correctness.
Working Model
Most practical queues provide at-least-once delivery under some failures, so handlers must expect duplicate and reordered messages. Correctness comes from preserving an explicit invariant across every permitted ordering, not from expecting one observed timing.
Practical Rules
- Record stable message IDs.
- Commit deduplication with the business change.
- Acknowledge only after durable success.
- Use per-entity versions or sequence numbers.
- Make poison-message policy observable.
Failure Modes
- Marking a message processed before the business update.
- Assuming global FIFO from a distributed queue.
- Retrying permanent validation failures forever.
- Performing external side effects without idempotency.
Verification
- Deliver the same message concurrently.
- Crash before and after commit.
- Reorder entity updates.
- Inspect retry and dead-letter records.
What You Should Be Able To Do
After this lesson, you should be able to explain at-least-once delivery, acknowledgement, deduplication, ordering, and idempotent consumers, choose a suitable approach for a real PHP project, and verify the result instead of relying on assumptions.
Practice
Practice: Build An Idempotent Consumer
Process InvoicePaid once under duplicate delivery.
Your answer must:
- state the intended outcome;
- show the commands, data flow, or implementation shape;
- identify at least one unsafe alternative;
- explain how the result will be verified.
Show solution
Use a unique message ID record in the same transaction as granting access. A duplicate insert or existing record returns the already-completed outcome.
The important part is not memorising one command or vendor screen. The solution makes the invariant, failure behavior, and verification evidence explicit.
Practice: Handle Out-Of-Order Events
Version 4 of a customer arrives before version 3.
Your answer must:
- state the intended outcome;
- show the commands, data flow, or implementation shape;
- identify at least one unsafe alternative;
- explain how the result will be verified.
Show solution
Store the latest applied version, apply only a newer valid version, ignore stale events, and define whether gaps trigger fetch, wait, or repair.
The important part is not memorising one command or vendor screen. The solution makes the invariant, failure behavior, and verification evidence explicit.
Practice: Design Dead-Letter Policy
A message repeatedly fails validation.
Your answer must:
- state the intended outcome;
- show the commands, data flow, or implementation shape;
- identify at least one unsafe alternative;
- explain how the result will be verified.
Show solution
Classify it as permanent, stop automatic retry after a bounded count, retain safe diagnostic context, alert an owner, and provide replay after correction.
The important part is not memorising one command or vendor screen. The solution makes the invariant, failure behavior, and verification evidence explicit.