Five Ways to Divide an Application

An architectural style is a way of dividing an application into parts, and five are common: the monolith, layers, microservices, event-driven and serverless. They differ in two things. The first is the unit of deployment: what gets built and released together. The second is how the parts talk: by calling code in the same process, by calls over the network, or by events.

Why the unit of deployment matters most. It decides who must coordinate to ship a change. In a monolith, every change ships with every other change, which is simple for one team and slow for twenty. With separate services, a team ships its own part alone, but parts now talk over a network that can be slow or fail.

Layered is the odd one out. Layers say how code is organised inside a deployable, into presentation, business logic and data access; they do not say how it is deployed. A monolith is usually layered, and so is each service in a microservices system.

Styles combine. A real system is rarely one pure style: an event-driven system is often built from microservices, and a monolith often hands its slow jobs to serverless functions.

What each card that follows covers. For every style, the same five things in the same order: its shape as a diagram, what it makes easy, what it makes hard, the team and product it fits, and one company known to use it.

So when you meet a style, ask first what ships together and how the parts talk; most of its strengths and costs follow from those two answers.