The block AI always forgets

Ask an AI to build a feature. It will forget one block. Every time.

Try it. Tell Claude to build video upload for your app. You will get a clean service: it receives the file, transcodes it, writes it to storage, and returns a response. It works. You demo it. Everyone nods.

Then you ship it, and the real world arrives.

A thousand users upload at once. Each request holds a connection open while the server grinds through transcoding. The server runs out of workers. New uploads time out. The feature that worked perfectly in the demo is now the reason your app is down.

The AI did not make a mistake. It answered exactly what you asked: upload a video. It just answered for one user, in a quiet moment, on a good day. That is the only world a demo lives in.

The block it forgot is the Queue. And the queue is strange, because it does almost nothing. It does not transcode. It does not store. It just holds messages. One part of your system drops a job in. Another part picks it up later. The two never talk to each other directly.

That word "later" is the whole point. A queue forces one uncomfortable question onto every task: can this be done later?

For a video upload, the honest answer is yes. The user needs to know the file arrived. They do not need to wait for it to be encoded into nine resolutions. So you split the work. The upload becomes a quick service that says "got it." The encoding goes into a queue, and workers chew through it at their own pace.

This is exactly how Instagram handles your post. When you tap Share, the upload is the quick service. Everything after it, the thumbnails, the feed fan-out, the notifications, the content moderation, rides a queue. That is why the post appears to publish instantly even though the work behind it keeps running for seconds after.

Now watch what the queue absorbs. A thousand uploads at once? They wait in line instead of crashing the server. An encoding service that dies at 2 AM? The jobs sit in the queue until it comes back, instead of vanishing. A viral post that triples your traffic? The line gets longer. Nothing falls over.

The queue did not speed anything up. It made the system survive being overwhelmed. Speed was never the point. Survival was.

Here is the trap, and it is the opposite of what you would expect. Once people learn about queues, they want to make everything async. The user clicks Purchase. The system queues it, flashes a success screen, and processes the payment in the background. Then the payment fails. Silently. The user walks away believing they bought something they did not.

That is the queue used in exactly the wrong place. The rule that prevents both mistakes is the same question, asked honestly: does the user need the result right now? If yes, it is a synchronous service, and a queue would lie to them. If no, it is background work, and a queue is what keeps it from taking down everything else.

AI will almost always reach for the service. The service is the happy-path answer, and the happy path is the only path a model sees unless you tell it otherwise.

In Course 1, the Queue is one of seven building blocks I teach, and it is the one that most often separates a demo from a system. Not because it is complicated. Because it is the block you do not miss until the night it would have saved you.

So before you ship the next thing AI built for you, ask its forgotten question yourself. Can this be done later? If it can, do it later. Your 2 AM self will thank you.

P.S. The queue is easiest to understand once you see it next to the worker that drains it. Full walkthrough, with the upload trace, is here: systemthinkinglab.ai/learn/building-blocks/queues/

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.