Faizal Azman

12 min readqueuesreliability

The queue is not the hard part

Picking the broker takes an afternoon. Deciding what happens to work you can never finish takes the rest of the project.

Picking the broker takes an afternoon. Every serious option delivers messages, survives a node loss, and has a client library someone has already fought with. That part is solved.

The hard part is the work you cannot finish

Every queue eventually holds an item that will never succeed. A malformed payload, a tenant that was deleted, a downstream that will not return. The interesting design question is not how the message got there — it is who is responsible for it now, and how they find out.

Dead letters are a workflow, not a topic

A dead-letter queue with no owner is a landfill. It grows, nobody reads it, and eighteen months later someone discovers that four thousand invoices were quietly not sent. If you create one, create the rota that drains it in the same commit.

Ordering is a promise you probably cannot keep

Partitioned ordering is real ordering only if your partition key is also your consistency boundary. Most teams pick a key that balances load, discover a year later that it does not match the boundary the business assumed, and find out through a support ticket.

Backpressure is the actual feature

A system that slows down under load is healthy. A system that accepts everything and buffers is deferring a decision it will have to make later, with less information and more customers watching.