Architecture: Apps, Sources & Storage

An architecture is just a map of the pieces of a system and how they connect. Don’t let the word intimidate you — at heart it’s a box-and-arrow drawing, the kind an engineer scribbles on a whiteboard to explain “here’s how it all fits together.” The good news is that most business systems share the same basic shape. Once you can read that shape, you can read almost any architecture diagram you’ll be shown in a meeting: a user talks to a front end, which talks to a back end, which reads and writes storage and pulls from external sources.

Following a request from screen to database and back

The easiest way to understand the diagram is to ride along with a single click. Imagine you log in to a website and press “Show my orders.”

First, the frontend — the part you see and touch, running in your browser or phone app — notices the click. The frontend’s job is presentation: buttons, layouts, the spinning loading icon. It generally doesn’t hold your data; it asks for it.

So it sends a request to the backend, also called the API. This is the brain. It contains the business logic — the rules about who’s allowed to see what, how to calculate a total, what counts as a valid order. The backend checks that you’re really you, then goes to fetch your orders.

To do that it reads from storage. It finds your records in the database, packages them up, and sends them back to the frontend, which paints them on your screen as a tidy list. The whole round trip — screen to backend to storage and back — usually happens in a fraction of a second. Almost every feature you’ve ever used is some version of this same loop.

A handy mental model: the frontend is the waiter, the backend is the kitchen, and storage is the pantry. You talk to the waiter; the kitchen does the work; the pantry holds the ingredients.

Sources versus storage

These two words sound similar and get muddled constantly, so it’s worth pinning down the difference.

A data source is where information comes from. That might be a user typing it in, another team’s system sending a feed, or an external API like a weather service, a payment provider, or a shipping carrier. Sources are about origin and flow — data arriving.

Storage is where data is kept for later. The two flavours you’ll hear about are a database (structured records, organised into rows and tables — think a giant, very fast spreadsheet) and object or file storage (whole files: documents, images, PDFs, backups). When someone asks “where does this data live?” they mean storage. When they ask “where does it come from?” they mean the source.

You’ll also hear about a data warehouse. That’s a large store optimised for analytics and reporting rather than for running the live app — the place the business pulls from to answer “how many orders did we ship last quarter?” without slowing down the system customers are using.

Reading any architecture diagram

Once you know the cast of characters, the boxes start to make sense no matter how a particular team draws them. Look for the user on one side and storage on the other. The boxes in between are doing logic. The arrows show which piece talks to which, and usually which direction the data flows. If you can point at a box and say “that’s the frontend, that’s the backend, that’s where the data lives, and that feed over there is an external source,” you are reading the diagram correctly — that’s genuinely most of the skill.

A few honest caveats. Real systems are messier than the clean three-box picture: there may be several backends (often called services or microservices), caches that keep popular data close for speed, and queues that pass messages between parts. But these are variations on the same theme. The core question never changes: where does the data come from, where does it live, and what logic sits in between?

Why it matters

Being able to read an architecture diagram changes how much of an engineering conversation you can follow. When someone says “the issue is in the backend, not the frontend,” you’ll know that means the logic or data layer is at fault, not the visible screen — and that it likely affects everyone, not just one user’s browser. When a project plan mentions “integrating a new data source,” you’ll know that means wiring in an external feed. And when someone asks where sensitive data is stored, you’ll understand they’re asking about the storage layer specifically. You don’t need to build these systems to benefit — you just need to recognise the shape.

Spot it: which part of the architecture?

Read each situation and decide for yourself, then tap a card to flip it and check your answer.

Sort the architecture pieces

Drag each item into the bucket it belongs to — or tap an item, then tap a bucket. Hit Check placement when you’re done.