Queue

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

A queue is a numbered tray of work. The API writes "send the welcome mail" on a slip, drops it in the tray, and answers the user. A worker pulls the next 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 can say "queued." The basement can be slow.

Cron is a clock that prints a slip when the hour hits. A queue is a line for slips that just happened. Agents 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 you must retry, imports, anything that can fail and come back. The 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 can have a perfect 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.