> ## 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, subscriptions, 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 interested subscriber gets its own copy — a queue, your project's API, or an external service. 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 subscriber, each with its own copy. | | Notify an external system when data changes | **Event Bus** | A subscription can deliver to an external HTTPS 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 and subscribe. To combine them, add a **subscription** 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 **subscription's filter** to see whether the event matches. 3. Every matching subscription receives its **own independent copy** and delivers it to its target — a queue, your project's internal API, or an external endpoint. 4. Endpoint deliveries are **retried** on failure and land in that subscription's **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 subscription tells you the error list isn't empty. 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. See the [API reference](/docs/features/backend/app-services/queues-and-event-bus/reference). When the Event Bus delivers to **your own project's API** (the default), authentication is handled for you — no URLs, no secrets. When it delivers to an **external** system, you provide the HTTPS URL and credentials, and Archie signs every 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 subscriptions with the two-step wizard — to a queue, your API, or an external endpoint. 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.