Skip to main content
Queues and the Event Bus are useful on their own, but they’re most powerful together. The Event Bus is great at broadcasting an event; queues are great at reliably processing work one item at a time. Connect them and you get the best of both: one event fans out to several independent workstreams, each of which is buffered, retried, and processed at its own pace. This is the classic fan-out then process pattern (in AWS terms, SNS delivering to several SQS queues).

​
The pattern in one picture

When you publish orders.created once, three teams react without knowing about each other:
Each queue holds its own copy of the event. If the billing worker is down for an hour, its copies wait safely in the billing queue and are processed when it returns — fulfillment and analytics are unaffected.

​
Why not deliver straight to your services?

You can subscribe your API directly to a topic. Putting a queue in the middle adds three things that matter in production:
  • Buffering — a spike of events is absorbed by the queue instead of overwhelming a downstream service.
  • Retries and an error list — a failed job is retried and, if it keeps failing, preserved in the queue’s error list instead of being lost.
  • Independent pace — each consumer drains its queue as fast as it can, fully isolated from the others.

​
Walkthrough: order created → three reactions

1

Create the queues

In the Queues panel, create the queues that will do the work — for example fulfillment, billing, and analytics. Accept the defaults unless a job needs special timing.
2

Create the topic

In the Event Bus panel, create a topic — for example orders.
3

Subscribe each queue to the topic

On the orders topic, add three subscriptions. For each one:
  • Step 1 (filter): choose One exact type and enter orders.created (or a pattern like orders.* if the queue should react to more).
  • Step 2 (target): choose Queue and select fulfillment, then repeat for billing and analytics.
4

Publish an event

From your app, publish once:
Or use the topic’s Publish test tab.
5

Watch the copies arrive

Open each queue — the Pending count on fulfillment, billing, and analytics each increases by one. Every subscribed queue got its own copy.
6

Let workers process each queue

Each worker runs its own loop — receiveMessages → do the work → deleteMessage — against its queue. They run independently and at their own pace. See Queues for the worker loop.
That’s the whole pattern: publish once, process in three isolated, retryable streams.

​
Together or separate — choosing per case

You don’t have to combine them. Pick the shape that fits each need:

​
Recipes

To make the system do one more thing when orders.created fires, create a new queue and subscribe it to the topic. Existing subscribers are untouched — they never know a new one was added. This is the safest way to grow an event-driven system.
Because each reaction has its own queue, you can tune them independently. Give billing a longer processing time and more max attempts than analytics, for example — one queue’s settings never affect another.
A topic can have both a Queue subscription (for heavy background work) and a Your API subscription (for a quick synchronous write) on the same event type. Each is independent.
Subscribe a queue for your own processing and an External endpoint for a partner, both to orders.created. Your internal work and the partner notification happen in parallel, each retried on its own.
If a downstream service was down, its queue simply accumulated the copies. When it recovers, its workers drain the backlog — no events were lost and nothing needs to be re-published.

​
Keep it reliable

Two habits make an event-driven system dependable:
  1. Make workers idempotent. Delivery is at least once, so a copy may occasionally arrive twice. Key your writes on a stable identifier (like orderId) so a repeat is harmless.
  2. Watch the error lists. A non-empty dead-letter queue (a red badge on a queue) or a failing subscription in Activity is your early warning. Fix the cause, then redrive.

​
Next

Reference & FAQ

The full list of operations, limits, statuses, and troubleshooting.

Back to overview

The concepts and when to use each service.