Architectural Styles

Zoom out from individual modules to the whole system, and you reach architecture — the highest-level shape of the software, how its biggest pieces are arranged. A handful of common shapes, called architectural styles, show up again and again, and each is a different tradeoff.

You don't need to design one yet — you need to recognize the names and what each is good and bad at: the monolith, microservices, layered and MVC, client-server, and event-driven. They're not ranked best-to-worst; each fits different situations.

A quick contrast to anchor the two you'll hear most: a monolith is like one big department store — everything under one roof. Microservices are like a street of specialist shops — each independent, but you walk between them.

The Monolith

A monolith is one single deployable application — all the features, all in one program, shipped as one unit. It's the simplest way to start: everything is in one place, easy to build and run, with no network hops between parts. Its downside shows up at scale: as it grows huge, every change touches one giant codebase, and you can't scale or update one piece independently of the rest.

Microservices

Microservices split the system into many small, independent services, each owning one capability and running on its own — a "users" service, a "reminders" service, a "billing" service. Each can be built, deployed, and scaled separately by different teams. The price is real operational complexity: now you're running and connecting dozens of programs over a network, which brings its own failures and overhead. Powerful at large scale, but a heavy cost to pay too early.

Layered and MVC

Other styles organize the inside of an app. A layered architecture stacks responsibilities — a presentation layer (the screens), a logic layer (the rules), a data layer (storage) — each talking only to the one below. MVC (Model-View-Controller) is a famous version that separates the data (Model), the display (View), and the glue that connects them (Controller). Both are really separation of concerns applied to a whole app, and they can live happily inside a monolith.

Client-Server and Event-Driven

Two more shapes describe how parts communicate. Client-server is the classic web pattern: a client (your browser or app) sends a request, a server answers — request and response, back and forth. Event-driven flips that around: instead of asking directly, parts announce that something happened ("a habit was checked off") and other parts react to those events on their own. Event-driven systems are looser and more flexible, but harder to trace, since no one is directly in charge of the flow.

Cadence starts as a sensible monolith — one app, easy for four people to build and run, no network maze. The team notes that if reminders ever grew into a huge, independently-scaling concern, they might split it into its own service. But with four people and modest traffic, that complexity would cost far more than it saves — so they don't. Choosing the simpler architecture on purpose is itself good design.