Before a single brick is laid, an architect draws a floor plan: where the load-bearing walls go, how the rooms connect, where the plumbing runs. You settle these decisions first, because once the concrete is poured they are ruinously expensive to change — you do not discover you wanted the kitchen on the other side of the house after the walls are up.
Software architecture is exactly this: the high-level structure of a system — how it is divided into components and how those components communicate. It is not about which loop you write or how you name a variable; it is about the big shapes: what the major pieces are, who is allowed to talk to whom, and where the data lives. Like a floor plan, it is decided early and is expensive to change later, so getting the shape roughly right matters more than getting any one line of code perfect.
Over decades, a handful of recurring shapes — architectural styles — have proven themselves. This page walks through the four you will meet most often: layered, client–server, microservices (versus the monolith), and MVC. For each, ask the same three questions: what is it, when do you reach for it, and what does it cost.
There is no "best" architecture, only the best fit for a set of pressures. Every style trades one good thing for another, and the whole skill is knowing which trade you are making. The forces you are usually balancing are:
A choice that helps one of these often hurts another — buying scalability, for instance, usually costs you complexity. Because these decisions are made early and are painful to reverse, an architect thinks in terms of which pain we can live with, not which option is flawless.
The oldest and most common style stacks the system into horizontal layers, each with one job, where a layer may only talk to the layer directly below it. The classic three are:
A request travels down the stack and the answer flows back up. Because each layer touches only its neighbour, you can swap the database or redesign the screens without rewriting the whole system — which makes layered systems easy to understand and maintain. The cost is a little indirection (a simple request still passes through every layer) and the risk that all the layers still ship as one big unit.
In the client–server style the system is split across machines: many clients (your phone app, a web browser) send requests over a network to a central server that holds the shared data and does the heavy work, then sends a response back. When you load a web page, check email, or play an online game, you are the client and somewhere a server is answering you.
Its great strength is centralisation: one authoritative copy of the data, one place to secure and update, and many lightweight clients that need not trust each other. The matching weakness is that the server is a single point of failure and a bottleneck — if it goes down, everyone is stuck, and if too many clients arrive at once it must be scaled up to keep up. Client–server is a distribution pattern (who runs where) and often sits alongside a layered design (how the server itself is organised inside) rather than competing with it.
A monolith packages the entire application as one single deployable unit: all the features — users, orders, payments — live in one codebase and ship together as one program. A microservices architecture instead breaks the system into many small, independently deployable services, each owning one capability and talking to the others over the network, usually behind an API gateway that routes incoming requests.
Microservices let separate teams build, deploy and scale each piece independently — if only "payments" is under heavy load, you scale just that service. But that power is bought with a steep price in operational complexity: now you are running a distributed system, with network calls that can fail, data spread across many services, and a fleet of things to deploy and monitor. A monolith is simpler to build, test and deploy — everything is in one place — but as it grows very large it can become hard to change and must be scaled as a whole even if only one part is busy.
It is tempting to think microservices are simply the modern, better choice and a monolith is old-fashioned — so a brand-new project should start with dozens of tiny services. This is a classic and costly mistake. Microservices are not "more advanced"; they are a different trade, buying independent scaling and team autonomy at the price of real operational complexity — network failures, distributed data, and a whole platform of deployment and monitoring to run. For most new or small systems a well-structured monolith (cleanly divided into layers or modules inside) is faster to build, easier to reason about, and perfectly scalable enough. The seasoned advice is often "monolith first": start simple, and split out a service only when a genuine, measured need appears. Choose microservices to solve a problem you actually have, not to look fashionable.
The last style zooms in on how to organise a single application — especially one with a user interface — into three cooperating parts, so that presentation and data do not tangle together. MVC splits the code into:
The point is separation of concerns: because the view only displays and the model only stores, you can redesign the look of an app without touching its rules, or change the rules without redrawing the screen. Follow the arrows below — user actions go from the view to the controller, the controller updates the model, and the model's data flows back out to the view.
Not really — they answer different questions and are happily used together. A layered architecture is a system-wide shape (presentation over logic over data). MVC is a finer-grained pattern for organising the presentation side of an application. In a typical web app, the whole thing is layered, and the presentation layer inside is arranged as MVC. Architecture is not a single choice from a menu; real systems layer several styles at different zoom levels — a client–server system whose server is layered, whose UI layer is MVC, and whose back end may be a monolith or a set of microservices.
These styles are a vocabulary, not a checklist. An experienced engineer picks and combines them to fit the forces on this system, knowing that the choice is made early and is dear to undo — so it is worth thinking hard about up front, and worth keeping as simple as the problem allows.