A team must choose between publish-subscribe and a work queue for a new integration. What distinguishes them, and which failure mode does each have?

The distinction

A work queue distributes tasks: each message is processed once, by one consumer. Adding consumers adds throughput. The producer knows work needs doing and does not care who does it.

Publish-subscribe distributes facts: each message reaches every interested subscriber. Adding subscribers adds recipients, not throughput. The producer states that something happened and does not know who cares.

The distinguishing question is whether the producer is requesting work or announcing a fact, and getting it wrong produces an architecture that resists the changes it will need.

The failure mode of each

Work queue: if the work is genuinely several different things — send an email, update an index, score for fraud — a single queue couples them. One slow consumer type delays the others, and a poison message affects work unrelated to it. The fix is a queue per consumer type, which is publish-subscribe with extra steps — and reaching that conclusion is the usual sign the original choice was wrong.

Publish-subscribe: the producer has no visibility of whether anything happened. A subscriber that silently stopped consuming produces no error anywhere, and the effect is discovered when someone notices missing results. Per-subscriber lag monitoring with an owner is not optional, and it is routinely absent.

The coupling nuance

Publish-subscribe is described as loosely coupled and it moves the coupling rather than removing it. Subscribers depend on the event's schema and on its semantics, and the producer cannot change either without knowing who depends on what.

Semantic coupling is the dangerous half: when the producer changes what an event means while its shape stays identical, nothing breaks and behaviour quietly diverges. That is the hardest failure to detect in an event-driven system.

The requirement that follows

A published schema with a compatibility policy, and a registry of who consumes what. Without both, an event-driven architecture becomes a system where nobody can change anything because nobody knows what depends on it — which is the coupling it was adopted to avoid, in a less visible form.