# Queue (/academy/queue)



The window can stamp. It should not also cook forty receipts at once.

A **queue** is a numbered tray of work. The [API](/academy/api) writes "send the welcome mail" on a slip, drops it in the tray, and answers the user. A [worker](/academy/worker) pulls the next [job](/academy/job) when it has hands. If 400 people sign up during the demo, they wait in the tray instead of melting the mail provider.

Three things the tray is for:

1. **It keeps the slip.** Restart the app. The work is still there — if you used a real queue, not an array in RAM.
2. **It sets a pace.** You handle what you can. The hallway can be a stampede. The tray does not have to be.
3. **It splits the rooms.** The thing that *creates* work does not have to *do* the work. The [frontend](/academy/frontend-backend) can say "queued." The basement can be slow.

[Cron](/academy/cron) is a clock that prints a slip when the hour hits. A queue is a line for slips that just happened. [Agents](/academy/agent) love to do everything in the same breath. Give them a tray when "now" would be 400 tabs.

create-hackhaton-space-stack will give you request handlers. A queue is what you add the moment "processing" is more honest than "done." Email, [webhooks](/academy/webhook) you must retry, imports, anything that can fail and come back. The [CLI](/academy/cli) does not hide a tray in the scaffold. You add one when the click and the leftover start fighting.

**What this unlocks**

"The system is up" and "this piece of work finished" become different sentences. A healthy app can have a backed-up tray. A dead [worker](/academy/worker) can have a perfect [API](/academy/api). Once you can name the line, you know which room to walk into.

The tray does not judge the work. It holds it until someone is free.