Orders must trigger inventory reservation, a confirmation email, an analytics record and a fraud check. Queue, topic, or both — and what breaks if you choose wrong?

What the interviewer is testing

Whether you know the difference between work distribution and notification — a distinction that produces one of the most confusing bug classes in messaging when it is got wrong.

Why a topic with per-consumer subscriptions

The four consumers each need every order event, and they must be independent: a fraud-check outage must not stop confirmation emails, and analytics falling behind must not delay inventory.

That is broadcast semantics, which is what a topic gives. Each consumer gets its own subscription (effectively its own queue), its own cursor, its own retry policy and its own dead letter queue. Within each subscription, competing consumers give horizontal scaling.

The producer publishes once and knows nothing about the four. Adding a fifth consumer later is zero change on the producing side, which is the decoupling being purchased.

What breaks with the alternatives

One shared queue is the classic mistake. A message goes to exactly one consumer, so each order would be handled by whichever service grabbed it — one order reserves inventory, the next sends an email, the next records analytics. If instead every service polls with its own filter, they compete and interfere. This is work distribution semantics applied to a notification problem.

One queue per service, written by the producer, works but recreates the coupling: the producer now knows all four consumers and must be changed to add a fifth. It also makes the four writes non-atomic — a producer that publishes to three queues and crashes has left the system inconsistent.

A polled database table costs latency, load and a bespoke cursor implementation per consumer, and it reinvents a broker badly. It is occasionally the right answer at very low volume when adding a broker is not justified — but say that explicitly rather than by accident.

What a strong answer adds

• The outbox. Publishing the event must be atomic with committing the order, or you have a dual-write bug: an order with no event, or an event for an order that rolled back.
• Delivery is at-least-once, so all four consumers must be idempotent. The email service especially — a duplicate inventory reservation is recoverable, a duplicate email is visible to the customer.
• Fraud check is arguably not a consumer at all. If a fraud result can block fulfilment, that is a synchronous gate or an explicit saga step, not a fire-and-forget subscriber. Noticing that one of the four does not belong in the list is the strongest thing you can say here.