The twelve boxes behind every app
DNS, CDN, auth, database, cache, queues, push. What each one does, and which to blame when it breaks.
Meer Habib
Senior Mobile Engineer · Chittagong
Every app you use, from a to-do list to a bank, is built from roughly the same twelve boxes. The names change and the vendors change, but the jobs don't. If you can picture these twelve and what each one is for, you can read almost any architecture diagram, and you'll know which box to blame when something breaks.
the way in
the core
everything after
The way in
01 · Phone. Your app. It holds a copy of some data, a queue of changes it hasn't sent yet, and the user's session. It's the only box you don't control once it ships, which is why it has to be the most forgiving.
02 · DNS. Turns api.example.com into an IP address, like a phone book. When a site "is down for some people", DNS is often the reason: changes take time to spread, and different people see different answers for a while.
03 · CDN / edge. Servers spread around the world that keep copies of things that don't change often, like images, scripts and app assets, close to the user. A photo loaded from a server in the next city arrives faster than one from across the ocean.
04 · Gateway. The front door for your API. It ends the encrypted HTTPS connection, spreads traffic across servers, and turns away abuse with rate limits. If the gateway is healthy but responses are slow, the problem is behind it.
The core
05 · Auth. Answers "who is this?". It checks passwords, social sign-in or passkeys, then hands out tokens the other boxes can verify on their own. Good auth means every other box can trust a token without asking again.
06 · API servers. Where your business rules live: validate the input, check permissions, talk to the database, shape the answer. They should be stateless, holding nothing between requests, so you can run one or fifty and any of them can answer.
07 · Database. The source of truth. Postgres, for example, stores rows in tables, keeps them consistent with transactions, and finds them quickly with indexes. A missing index is the most common reason a screen that was fast with 100 users is slow with 100,000.
08 · Cache. A fast, in-memory copy of answers that are expensive to compute, like Redis. It makes reads cheap. The hard part is knowing when a cached answer is out of date, which is why caching is famously one of the two hard problems in computing.
Everything after
09 · Queue + workers. Work that doesn't need to finish before the user sees a response goes in a line: send the email, resize the photo, call the webhook. Workers take jobs off the line and retry the ones that fail. This is how an app stays fast while doing slow things.
10 · Object storage. Where files live: photos, voice notes, PDFs, backups. You don't stream files through your API. Instead the API hands the app a short-lived signed URL, and the app uploads or downloads directly.
11 · Realtime. A connection that stays open, usually a WebSocket, so the server can push changes to the app the moment they happen. Chat messages, live cursors, a note appearing on your other phone.
12 · Push. Apple's APNs and Google's FCM. The only way to reach an app that isn't open. Your server asks Apple or Google to deliver a message; they decide when. That's why pushes are great for "you have a message" and bad for anything that must arrive on time.
The thirteenth box
Around all twelve sits observability: logs, metrics and traces. Give every request an ID when it enters, pass it through every box, and write it in every log line. When a user says "it didn't save", that ID turns a mystery into a search.
How a small team builds this
You don't run twelve services on day one. Platforms like Supabase and Convex bundle most of the core into one: auth, database, storage, realtime, background functions. That's what I reach for when starting a product. You still need to know the boxes, because the day something is slow, you'll need to know which one to open.
For how a single request travels through these boxes, see from tap to database and back.
Building something like this?
Booking new projects for Q4. Replies within 24h.