Event bus versus message queue for triggers

WHAT THIS TESTS This checks whether you can pick the right messaging primitive by distinguishing point-to-point delivery from content-based fan-out routing.

A GOOD ANSWER COVERS A message queue such as SQS is point-to-point: producers enqueue messages and one logical consumer group pulls and processes each message once, then deletes it. It excels at buffering, load leveling, decoupling a producer from a single downstream worker, retries, and smoothing spikes. An event bus such as EventBridge is publish-subscribe with routing: a producer publishes an event, and rules match on event content to deliver copies to many independent targets. It decouples a producer from a dynamic, unknown set of consumers and supports filtering, schema discovery, and integration across services and accounts. The key difference: a queue connects one source to one consumer flow, while an event bus broadcasts one event to many reactions selected by rules. You can combine them, often fanning out from a bus into per-consumer queues.

COMMON WRONG ANSWERS Calling them interchangeable. Saying SQS supports multiple independent subscribers to the same message, which it does not within one queue. Ignoring EventBridge content-based routing. Missing that buffering and retry are queue strengths.

LIKELY FOLLOW-UPS How do you get fan-out with SQS, via SNS or a bus into multiple queues? How does content filtering work? When do you put a queue behind a bus target? Ordering and exactly-once concerns?

ONE CONCRETE EXAMPLE When an order is placed, an OrderPlaced event goes to EventBridge, whose rules fan it out to a billing service, an inventory service, an email notification function, and an analytics pipeline, each reacting independently. A single SQS queue could not cleanly deliver that one event to four unrelated consumers, so the event bus is the superior choice here.