Message Queues vs Service Bus

The real fork: point-to-point vs publish/subscribe

"Message queue vs service bus" sounds like a choice between two products, but underneath it is a choice between two delivery semantics. A point-to-point queue hands each message to exactly one consumer out of a pool of competing workers — a single ticket that one cashier will serve. A service bus (or any publish/subscribe broker: Azure Service Bus topics, RabbitMQ topic exchanges, SNS fanning out to per-subscriber SQS queues) broadcasts each message to every interested subscriber independently — a company-wide announcement that every department acts on in its own way. Routing rules, transformation, orchestration, and operational cost all follow from that one structural difference.

Message queues: one message, one worker

Definition

A message queue is a buffer between a producer and a pool of workers. The producer enqueues a unit of work; any one available worker dequeues it, processes it, and acknowledges it. Once acknowledged, the message is gone — no other worker will ever see it.

How delivery actually works

• Visibility timeout / lease: when a worker pulls a message, the queue hides it from other workers for a configurable window (e.g. 30s). If the worker doesn't ack within that window, the message reappears and another worker can pick it up.
• At-least-once delivery: because acks can be lost or workers can crash mid-processing, the same message can be delivered more than once. Consumers must be idempotent.
• Dead-letter queue (DLQ): after N failed delivery attempts, the queue moves the message to a separate DLQ instead of retrying forever, so one poison message can't stall the whole pipeline.
• Ordering: plain queues (SQS standard, generic AMQP queues) give no ordering guarantee across workers; FIFO variants (SQS FIFO, single-consumer RabbitMQ queues) trade throughput for strict order.

Where it fits

Use a queue when you have one logical job that needs to happen exactly once, spread across a pool of interchangeable workers: resizing an uploaded image, sending a single email, charging a card. The queue's only job is to make sure the work happens once, survives a crash, and doesn't overload downstream systems.

Service bus / publish-subscribe: one message, every interested subscriber

Definition

A service bus (classically an Enterprise Service Bus, or more commonly today a topic-based broker) delivers each published message to every subscription registered on that topic, independently of the others. Azure Service Bus topics, RabbitMQ topic exchanges, and SNS fanning out to multiple SQS queues are the same pattern under different names: one publish, many independent deliveries.

Characteristics

• Fan-out delivery: publishing to a topic can trigger a billing update, an email notification, and an analytics event from a single publish call — each subscriber has its own queue/lease/ack cycle and never blocks the others.
• Routing and filtering: subscribers can attach filter rules (e.g. only orders over $500) so they receive a relevant subset of the topic's traffic instead of everything.
• Transformation and mediation: heavier ESB implementations add content-based routing, protocol translation (SOAP to REST), and schema transformation in the broker itself.
• Centralization: the bus becomes the one place that knows about every producer and consumer relationship in the system — useful for visibility, risky as a single coordination point.

Where it fits

Use a service bus / pub-sub topic when one event needs to trigger multiple, independent reactions that shouldn't know about each other: "order placed" needs to update inventory, charge the card, send a confirmation, and update analytics — four different services with four different SLAs, none of which should block or even know about the others.

Worked example: message #8842, from enqueue to redelivery

Scenario 1 — normal path (order-confirmation email)

An order service places message #8842 ("send confirmation email for order 91204") onto a queue at t=0s.

• t=2s — Worker A polls the queue, receives message #8842, and starts a 30-second visibility timeout lease on it.
• t=2s–t=40s — Worker A calls the email API. The call is slow (38s) because the provider is under load, but it eventually succeeds.
• t=32s — the visibility timeout expires before Worker A acks, because 38s of processing exceeds the 30s lease. The queue assumes Worker A died and makes #8842 visible again.
• t=33s — Worker B polls the queue, also receives #8842 (a second, redundant delivery of the same message), and starts its own 30-second lease.
• t=40s — Worker A's slow API call finally returns success and Worker A tries to ack #8842. What happens now is broker-specific: in a lock-token broker (Azure Service Bus), A's lock already expired at t=32s, so A's ack is rejected with a lock-lost error; in SQS, A's delete carries a now-stale receipt handle — the API call returns success, but AWS documents that the message "might not be deleted."
• t=45s — Worker B's own call to the email API also succeeds, and B acks with the lock/handle it holds: in Service Bus B's ack succeeds (B owns the current lock), and in SQS B's newer receipt handle deletes the message. Note what did not depend on any of that: both workers already called the email API, so the customer has two confirmation emails either way — at-least-once delivery made the duplicate side effect happen before any ack bookkeeping could matter.

This is why consumers must be idempotent (e.g. de-duplicate on order ID before sending) and why the visibility timeout should be sized above your p99 processing time, not your average.

Ack-race semantics by broker

Who "wins" the t=40s/t=45s ack race is a per-broker contract, not a law of queues:

The invariant across all three: the ack protocol protects the queue's bookkeeping, never your side effects — only idempotency protects those.

Scenario 2 — a separate, hypothetical replay: what if the email API stays down for good?

This is a fresh, independent branch, not a continuation of Scenario 1 above. Rewind the clock back to t=0s and replay the exact same message #8842 from scratch, this time assuming the email API is permanently unreachable rather than merely slow.

• t=0s–t=30s — Worker A receives #8842, calls the email API, gets connection refused, and its handler crashes without acking or explicitly failing the message.
• t=30s — the lease expires; #8842 becomes visible again.
• This repeats: Worker B picks it up, fails, its lease expires; Worker A picks it up again, fails again — a redelivery loop, each attempt roughly 30 seconds apart.
• After the queue's configured maxReceiveCount (say, 5 attempts), the broker stops retrying and moves #8842 to the dead-letter queue instead of looping forever.

An on-call engineer inspects the DLQ, sees the email API has been down for 20 minutes, fixes the underlying outage, and replays the DLQ contents back onto the main queue. Without a DLQ, this failure mode would consume worker capacity indefinitely and could starve unrelated messages behind it.

When to use which — and what it costs you

Use a plain message queue when

• Exactly one worker should do the job, and any worker in the pool is interchangeable (resize one image, send one email, charge one card).
• You want to load-level a spiky producer against a slower downstream system by letting the queue absorb the burst.
• You have a single logical consumer group and no need for other services to independently react to the same event.

Do not use a plain queue when

• More than one independent service needs to react to the same event — a queue only gives the message to one consumer, so bolting on a second consumer means either racing for the same messages or building your own fan-out on top, which is exactly what a topic already does for you.
• You need content-based routing, protocol mediation, or in-flight transformation — a queue is a dumb pipe by design, and forcing routing logic into consumer code just relocates the complexity you were trying to centralize.

Benefits you get from a plain queue: minimal moving parts (one queue, one DLQ, one retry policy to reason about), horizontal scaling by adding workers with no coordination between them, and low latency because there's no fan-out or filter evaluation on the hot path. What it costs you: no visibility for other teams into what's flowing through the queue, and if a second consumer later needs the same events, you're re-architecting rather than just adding a subscription.

Use a service bus / pub-sub topic when

• One event genuinely needs multiple, independently-scaled, independently-failing reactions (billing, email, analytics, and audit log all reacting to "order placed").
• You need routing or filtering so each subscriber only sees the slice of traffic relevant to it, instead of every consumer inspecting and discarding messages it doesn't care about.
• You want to add a new consumer of an existing event stream without touching the producer or any existing consumer — just add a subscription.

Do not use a service bus when

• You only have one consumer today and no credible plan for a second — you're paying fan-out overhead and operational surface area for a feature you're not using.
• Your team can't own the operational burden of a broker cluster, per-subscription DLQs, and routing-rule configuration — a managed point-to-point queue is far cheaper to run correctly.
• Strict, global ordering across all consumers matters more than independent scaling — fan-out to independently-paced subscribers makes cross-subscriber ordering guarantees expensive or impossible.

Benefits you get from a service bus: new consumers are additive (no producer change), each subscriber fails and retries independently so a broken email service can't stall billing, and routing rules push filtering logic into infrastructure instead of scattering "if type == X" checks across every consumer. It costs you: operational weight (a broker cluster, per-subscription DLQs, and routing-rule configuration to provision and monitor instead of a single queue), higher end-to-end latency on the hot path because every publish now pays for topic matching and per-subscription fan-out rather than a single direct handoff, harder debugging because a single logical event now has N independent delivery timelines to trace instead of one, and a bigger blast radius for misconfiguration — a bad filter rule or a forgotten subscription silently drops an entire class of downstream reactions instead of failing loudly.

A third option: log-based streaming (Kafka)

Neither a queue nor a service bus is the only alternative. A log-based platform like Kafka keeps every message on a durable, ordered, replayable log per partition and lets each consumer group track its own read offset — closer to "subscribers can rewind and replay history" than either a queue (message is gone once acked) or a classic pub/sub bus (delivered live, not typically replayed). Reach for Kafka instead of a queue or a service bus when consumers need to replay historical events (rebuilding a cache, backfilling a new service), when message volume is high enough that per-message broker bookkeeping (leases, acks, DLQs) becomes the bottleneck, or when you want strict ordering within a partition preserved across multiple independent consumer groups. The cost: you take on partition and offset management, and "delivery" becomes "read position" — a different mental model your team has to learn, not a drop-in swap for either a queue or a bus. The reverse crossover is worth naming too: a classic service bus (Azure Service Bus) beats Kafka when you need features Kafka does not ship — message sessions (ordered, stateful sub-streams keyed by a session ID), broker-side transactions across multiple sends/receives, per-message scheduled delivery and dead-lettering, and managed enterprise protocol connectors/mediation. Kafka wins on retention, replay, and raw partitioned throughput; the bus wins on transactional, session-ordered, protocol-rich enterprise integration.

Variable-duration jobs: renew the lease, do not set a one-hour timeout

A static visibility timeout works when processing time is tightly distributed. It breaks for variable tasks: if file jobs take anywhere from 10 seconds to 1 hour, setting the timeout to 1 hour delays retry for a worker that crashes at second 11; setting it to 30 seconds causes duplicate work for every legitimate long job. That is the visibility-timeout dilemma.

The production mechanism is active lease renewal, also called heartbeating. Start with a short timeout, such as 60 seconds. While the worker is healthy and still making progress, it periodically extends the message lease before it expires. In AWS SQS this is ChangeMessageVisibility; other brokers expose the same concept as renew-lock, extend-lease, or touch. If the worker crashes, heartbeats stop and the message becomes visible after only the short timeout. If the worker is alive for an hour, it keeps extending the lease and avoids duplicate delivery.

Make renewal progress-aware: renew only after durable progress, cap the maximum total lease time, and send the message to a DLQ after repeated failures. Otherwise a wedged worker that keeps heartbeating can hide a poison message forever.

The operability tell for both patterns is the same: alert on DLQ depth and message age, not only on queue lag. A queue can show near-zero lag while every message is quietly failing into the DLQ, and a session/affinity-based subscription can wedge when its sticky consumer host dies — both are invisible to a lag-only dashboard. Watch DLQ arrival rate, oldest-message age, and (for pub/sub) per-subscription backlog so a single broken subscriber surfaces loudly instead of silently dropping a whole class of downstream reactions.

Sources

Concepts and terminology cross-checked against: the AWS SQS developer guide (visibility timeout, at-least-once delivery, dead-letter queues), the Azure Service Bus documentation (topics, subscriptions, filter rules), the RabbitMQ documentation (topic exchanges, competing consumers), and the Apache Kafka documentation (log-based retention, consumer groups, offsets).