Skip to main content
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 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

Queues

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.

Event Bus

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

​
Activate one, the other, or both

There is nothing to “install”. Both services live under App Services and become available per environment:
1

Open the panel

Go to Backend → App Services → Queues or App Services → Event Bus in the environment you want to work in.
2

Create your first resource

Create a queue (Queues panel) or a topic (Event Bus panel). The underlying infrastructure is provisioned for you automatically, scoped to this (project, environment).
3

Use them independently or connect them

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.
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

Queues

Create a queue, tune its settings in plain language, send a test message, watch its health, and handle errors.

Event Bus

Create a topic, publish events, and add subscriptions with the two-step wizard — to a queue, your API, or an external endpoint.

Using them together

The fan-out-then-process pattern: broadcast one event and have several queues handle their copies independently.

Reference & FAQ

The GraphQL operations, limits and defaults, message statuses, and answers to common questions.