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, routes, 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 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

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

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 routes with the two-step wizard — to a queue, a REST endpoint, or GraphQL.

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.