Message Queues & Event-Driven Systems

Point-to-point messaging is the simplest queue model. Producers write independent units of work to a queue. Consumers compete for those messages, and a single message is normally completed by one consumer.

The queue decouples producer speed from consumer speed. If producers temporarily create 20,000 jobs per second while workers process only 10,000, the backlog grows instead of forcing every producer request to wait for workers.

This model is ideal when the work itself should happen once, not once per subscriber. If three independent systems all need the same event, use pub-sub or an event stream instead of putting all three systems behind one competing-consumer queue.

A work queue is a point-to-point queue specifically used to distribute jobs across a worker pool. Every worker runs the same or compatible processing logic and competes for available work.

The most important design controls are worker concurrency, prefetch/batch size, acknowledgement timing and downstream capacity. Fetching too many jobs per worker can create unfairness; fetching too few can underutilize workers.

Work queues are commonly autoscaled from queue depth, oldest-message age, consumer utilization or processing latency. Queue depth alone is not enough because a queue containing ten 30-minute video jobs is very different from ten 20-millisecond jobs.

Pub-sub is used when an event is interesting to multiple independent systems. A publisher writes to a topic or exchange, and subscriptions independently receive the event.

Each subscriber owns its own processing progress. Notification can fail while analytics succeeds. This independence is one of the biggest benefits of event-driven architecture.

Pub-sub should represent something that happened, such as ORDER_CREATED or PAYMENT_SUCCEEDED, rather than a tightly coupled remote procedure call disguised as a message whenever possible.

Fanout is a broadcast routing pattern. The publisher does not select a destination using a routing key; every bound queue/subscriber gets the message.

It is useful for system-wide events where all subscribers care about the same information. It is intentionally less selective than topic routing.

Because one input message becomes many deliveries, fanout can multiply traffic substantially. Payload size, subscriber count and retry behavior should be considered before broadcasting high-volume events.

Topic routing sits between one-to-one queues and full broadcast. Producers publish a meaningful routing key such as payment.success, payment.failed or order.created.

Subscribers bind to exact keys or patterns such as payment.*. This keeps unrelated traffic away from consumers and makes ownership clearer.

Topic taxonomies are part of architecture. Without naming conventions and schema ownership, organizations accumulate ambiguous event names and brittle consumers.

FIFO is needed when processing M2 before M1 would produce an invalid state. A common example is CREATED -> PAID -> SHIPPED for the same order.

The strongest form, global ordering, severely limits parallelism because all messages effectively pass through one ordering lane. Large systems therefore prefer per-entity or per-key ordering.

A practical design hashes orderId, bookingId or accountId to a partition/message group. Different entities run in parallel while events for the same entity remain ordered.

Priority queues are useful when not all work has equal urgency. Security incidents, payment reconciliation or premium interactive jobs may need to jump ahead of marketing or batch work.

A single priority number is not enough for production design. You must prevent starvation of low-priority work through aging, weighted scheduling or reserved worker capacity.

Many teams use separate queues per priority because it gives clearer capacity controls and avoids broker-specific priority behavior.

Delayed queues represent future work without repeatedly scanning a database. The broker or scheduler stores a job until its due time and then makes it consumable.

This is useful for booking expiry, retry-after delays, reminder notifications and cart abandonment. The delay should be treated as approximate unless the technology explicitly provides strict scheduling guarantees.

For extremely large scheduling horizons or millions of long-term timers, consider whether a dedicated scheduler plus durable database is more appropriate than keeping every future task inside a broker.

Retries are for transient failure: network timeouts, temporary 5xx responses, rate limits or short dependency outages. Permanent validation errors should not loop through retries forever.

A strong retry design uses bounded attempts, exponential backoff and jitter. Jitter prevents thousands of failed messages from retrying at exactly the same second and recreating the outage.

Many architectures use retry tiers such as 5 seconds, 30 seconds and 5 minutes before moving to a DLQ. The original attempt count and failure reason should travel with the message metadata.

A DLQ prevents poison messages from blocking healthy traffic forever. Messages usually arrive after exhausting retries, failing validation or violating processing rules.

The DLQ is not the end of the design. Production systems need alerts, dashboards, failure metadata, inspection tooling and a safe replay path after the underlying bug or data issue is fixed.

Blindly replaying an entire DLQ can repeat the outage. Replay should be rate-limited, observable and often filtered by failure reason or event version.

Request-reply can be built on a broker when asynchronous transport is required but the caller still expects a response. The request carries a correlationId and usually a reply destination.

This pattern is more complex than normal HTTP/gRPC because you must handle timeouts, abandoned replies, correlation state and duplicate responses. It should not be chosen merely to avoid synchronous APIs.

It is useful across unreliable or disconnected boundaries, long-running operations or messaging-only environments. For ordinary low-latency service-to-service calls, HTTP/gRPC is often simpler.

A stream/log differs from a traditional destructive queue. Consuming an event usually advances a consumer offset rather than deleting the event immediately for everyone.

Retention makes replay possible. A new analytics consumer can start from older offsets, or an existing consumer can rebuild state after a bug fix.

Partitioning provides scale. Events with the same key are routed to the same partition for ordered processing, while unrelated keys are processed in parallel across partitions.