> ## Documentation Index > Fetch the complete documentation index at: https://archie.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Queues & Event Bus > Move work into the background and broadcast events across your app. Use Queues to process jobs reliably one at a time, the Event Bus to fan one event out to many places, or both together — all scoped per environment. Queues and the Event Bus are Archie's two building blocks for **asynchronous work** — anything your app should do *after* responding to a user, or *in reaction to* something that happened elsewhere. They let you decouple the moment something happens from the work it triggers, so a slow task never blocks a request and one event can reach many places at once. To access this section, open a project, switch to the **Backend Console**, and look under **App Services → Queues** and **App Services → Event Bus** in the left-hand sidebar. Queues and the Event Bus are scoped **per environment**. Each [environment](/docs/features/backend/environments/overview) keeps its own queues, topics, routes, and message history, so what you set up in `development` never touches `production`. ## The two building blocks in plain language A **to-do list for your app**. Each message is picked up by exactly one worker, processed, and removed. Perfect for background jobs: sending an email, resizing an image, charging a card. A **loudspeaker**. You publish one event to a *topic*, and every matching *route* gets its own copy — a queue, a REST endpoint, or GraphQL. Perfect for "when X happens, do A, B, and C". If you have used AWS before: a **Queue** is Archie's equivalent of **SQS**, and the **Event Bus** is the equivalent of **SNS / EventBridge**. You don't need to know either to use them — the panels speak in product terms, with the technical name in parentheses. ## When to use which | You want to… | Use | Why | | ----------------------------------------------------------------------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Run a slow task without making the user wait | **Queue** | The request returns immediately; a worker picks up the job later. | | Guarantee each job is handled by exactly one worker | **Queue** | A message is delivered to a single consumer at a time, and retried if it isn't confirmed. | | Smooth out spikes so a burst doesn't overwhelm a downstream service | **Queue** | Messages wait in line and are consumed at a steady pace. | | React to something with **several** independent actions | **Event Bus** | One published event fans out to every route, each with its own copy. | | Notify an external system when data changes | **Event Bus** | A route can deliver to an external REST or GraphQL endpoint, signed and retried. | | Both: broadcast an event **and** process each copy reliably in the background | **Both, together** | A topic fans out to one or more queues; workers drain each queue at their own pace. See [Using them together](/docs/features/backend/app-services/queues-and-event-bus/using-them-together). | ## Activate one, the other, or both There is nothing to "install". Both services live under **App Services** and become available per environment: Go to **Backend → App Services → Queues** or **App Services → Event Bus** in the environment you want to work in. Create a **queue** (Queues panel) or a **topic** (Event Bus panel). The underlying infrastructure is provisioned for you automatically, scoped to this `(project, environment)`. A queue works on its own — send and receive messages. A topic works on its own — publish events. To combine them, add a **route** on a topic whose target is a queue. You can adopt these features **incrementally**. Start with a single queue for one background job, or a single topic for one broadcast. Nothing else in your project changes, and neither service is required by the other. ## How a message flows Understanding the path a message takes makes the panels self-explanatory: **Queue (point-to-point).** 1. Your app **sends** a message to a queue. 2. The message waits as **Pending** until a worker asks for it. 3. A worker **receives** the message; it becomes **In flight** (invisible to other workers) for a limited time. 4. The worker finishes and **confirms** (acknowledges) it — the message is removed. 5. If the worker never confirms (crash, timeout), the message becomes visible again and is **retried**. After too many failed attempts it moves to the **error list (dead-letter queue)** for inspection. **Event Bus (fan-out).** 1. Your app **publishes** an event to a topic (an *event type* plus a JSON payload). 2. The topic checks each **route's filter** to see whether the event matches. 3. Every matching route receives its **own independent copy** and delivers it to its target — a queue, your project's own GraphQL API, or an external REST/GraphQL endpoint. 4. Endpoint deliveries are **retried** on failure and land in that route's own **error list** if they keep failing. You can watch every attempt in the **Activity** tab. ## Key ideas that apply to both A queue or topic created in `development` is completely separate from one with the same name in `production`. Switching the environment selector refreshes everything; the two never mix. Both services guarantee a message is delivered **at least once**, and may occasionally deliver a duplicate (for example, if a worker processed a job but crashed before confirming). Design your workers to be **idempotent** — safe to run twice with the same input. Sending a message with a **dedup key** also suppresses accidental duplicates within a short window. When a message can't be processed after its configured number of attempts, it moves to a **dead-letter queue (DLQ)** — an "error list" — instead of disappearing. You can inspect it, fix the cause, and **redrive** (retry) it. A red badge on a queue, or a non-zero **Failed** count on a topic, tells you something needs attention. Every REST or GraphQL route has its own dead-letter queue, separate from any Queues-panel queue. Every action in the Queues and Event Bus panels has a matching **GraphQL** operation, so you can automate the same tasks from your app or scripts. The panel is the friendly front door; the API is the same door for machines. Note that the API still calls a route a **subscription** — the UI renamed the concept, the schema didn't. See the [API reference](/docs/features/backend/app-services/queues-and-event-bus/reference). Delivering to **your own project's API** (GraphQL, the default) skips the URL — you pick an existing mutation instead of writing one — but you still provide a **Token / API key** for authentication. Delivering to an **external** system needs the HTTPS URL and, for REST, is the only option today (internal REST delivery is coming). Archie signs every external request so the receiver can verify it came from you. ## Where to go next Create a queue, tune its settings in plain language, send a test message, watch its health, and handle errors. Create a topic, publish events, and add routes with the two-step wizard — to a queue, a REST endpoint, or GraphQL. The fan-out-then-process pattern: broadcast one event and have several queues handle their copies independently. The GraphQL operations, limits and defaults, message statuses, and answers to common questions.