You Probably Do Not Need a Queue Yet

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

An agent building your backend will happily add a message broker. It is a reasonable-looking choice, it appears in every architecture diagram, and it turns one running thing into three — which is three times the memory to size, permanently. An agent working from the project's recorded rules would have argued from your constraints instead.

Most small applications do not need one. A table in the database you already have will carry background work correctly until you have real load — and it will be far easier to debug at three in the morning.

The useful question is not "which broker" but "what is this work allowed to do to a request". If a slow job must not hold a page open, you need somewhere to put it. That somewhere starts as a table.

A table is a queue until proven otherwise

Rows with a status column, claimed by a worker, marked done. That is a queue. It is transactional with the rest of your data, inspectable with the same tools, and recoverable by hand when something goes wrong.

You give up throughput and fan-out. For a product with tens of thousands of jobs a day rather than millions, that trade is almost always worth taking, because the thing you keep is the ability to answer "what happened to this job?" with a single query.

The failure mode to design for is not volume. It is a worker dying halfway. Claim a row with a timestamp, treat a stale claim as retryable, and be explicit that a released claim is not the same as a failure — nothing was learned, so nothing should be recorded as broken.

A cache is not a substitute for thinking about your queries

Caching is the other thing that arrives early and unexamined. A cache in front of a slow query hides the query. That is fine when the query is genuinely expensive and the data tolerates being stale; it is a trap when the real problem was a missing index.

Reach for a cache when you have measured the cost and can name what staleness is acceptable. Sessions, rate counters, a rendered fragment that changes hourly — those are cache-shaped. Anything you would be upset to serve five minutes late is not.

And remember what a cache is allowed to do: forget. If losing it costs more than a repopulate, it was never a cache — it was a database you have not backed up.

What actually moves you past a table

Three signals, in the order they usually arrive.

• The work must outlive the request by a lot. Minutes, not seconds — a video to transcode, a report to build. Polling a table every second to feel responsive is a sign you want a broker's push instead.
• Several consumers want the same event. Fan-out in SQL means every consumer polls, and adding the fourth one means changing the third.
• Retry and dead-letter handling has become its own codebase. Once you have written scheduling, backoff and a poison-message path yourself, you have written a broker — badly, and only you can maintain it.

None of these is about scale in the abstract. Each is a specific thing your code is being asked to do that a table makes awkward — which is a much better reason to add infrastructure than the diagram looking incomplete. It is the same discipline as choosing where an app runs: pick for what must keep working, not for what sounds serious.

FAQ

Is using a database table as a queue an anti-pattern? Not at small scale. It becomes one when you are fighting lock contention or polling hard enough to hurt the database — both measurable, neither hypothetical.

What breaks first if I do this? Usually claim handling. A worker that dies holding a row leaves it stuck until something releases it, so write that path before you need it.

Should I let an AI agent choose the architecture? Let it propose and make it justify. An agent working from the project's recorded rules argues from your constraints; one working from a blank page argues from the average of everything it has read.

When does the cost of running a broker become worth it? When the alternative is code you maintain that does the same job. On aidrop.it a managed cache and queue start on the $99 plan for exactly that reason — below it, a table and a database are what most projects actually need.

Do I need both a cache and a queue, or one? They solve unrelated problems. Needing one says nothing about needing the other, and adding both because they arrive together is how a two-container app becomes four.

Cover: https://unsplash.com/photos/h2rWePLKxvs by Hyundai Motor Group on Unsplash. Alt text: Cardboard boxes moving along a conveyor belt inside an industrial sorting facility.