The Queue Is Not a Database

A queue can deliver a message twice, out of order, or much later than expected. Reliable systems keep the source of truth in durable storage and treat the queue as a delivery mechanism with explicit retry and dead-letter behavior.

Durable state first

Persist the command and its current status before publishing work. If publishing fails, an outbox record can be retried. If the consumer runs twice, the handler can use the command ID as its idempotency key. This gives the system a durable story for both sides of the queue.

Operational questions

Measure queue age, retry count, dead-letter volume, and the time between acceptance and completion. Those signals tell you whether the problem is throughput, a poisoned message, or a dependency that is failing slowly.