Cheat sheet: Architecture styles
Every style on one page: its memory hook and the points worth saying out loud. Print it (Ctrl/⌘ P) and re-read it before a practice session; open the page behind any card when something doesn't come back to you. Built automatically from the pages, so it always matches them.
Inside one application
Monolith and modular monolith
“One kitchen, walled stations”
One deployable is fine; one undivided codebase isn't. Keep the single kitchen, but give each station its own space.
- Avoid
- The big ball of mud
- Splitting too early
- Scaling everything for one hot part
Layered
“Counter, back office, vault”
Each layer has one technical job and talks only to the layer below it.
- Avoid
- The sinkhole
- Rules leaking up or down
- Layers mistaken for modules
Hexagonal (ports and adapters)
“The laptop decides the socket”
The core declares ports in its own language; technology plugs in from outside.
- Avoid
- Ports that mirror a vendor
- Logic in adapters
- A port per table
Clean and onion
“Rings point inward”
The innermost code changes least and knows least; everything outside depends on it.
- Avoid
- Rings as a folder template
- Entities that are only data
- Leaking framework types
Microkernel (plugins)
“A stable console, new games”
Keep the core small and stable; let plugins carry the variation through a versioned contract.
- Avoid
- A fat core
- A leaky contract
- Plugin order bugs
Across machines
Client-server and tiers
“Ask at the desk”
Clients ask, servers answer; the server side is split into tiers on separate machines, each stateless and talking only to the next.
- Avoid
- Sticky state
- Chatty tiers
- Two-tier over the internet
Service-based and SOA
“A few departments, one records office”
Coarse services per business area, deployed separately, sharing a database that needs an owner per table.
- Avoid
- The shared database as a hidden API
- Logic in the bus
- Too fine, too soon
Microservices
“Stalls in a market”
Small services, each owned by one team, deployed alone, with their own data, cooperating through APIs and events.
- Avoid
- The distributed monolith
- Too small
- Long synchronous chains
Serverless
“A taxi, not a car”
Code runs per event on a platform you don't operate, billed per use; great for spiky or small work, pricey at steady volume.
- Avoid
- Cold starts on the hot path
- Connection storms
- Steady high load on functions
Moving data and messages
Event-driven
“The departure board”
Parts announce facts; whoever cares reacts, in its own time, without the announcer knowing.
- Avoid
- Events as remote calls
- No one can see the flow
- Ignoring lag
Pipes and filters
“The car wash”
Data flows through independent steps that each do one job, connected by pipes.
- Avoid
- Steps that need the whole dataset
- Errors that stop the line
- Too many tiny steps
Broker
“The switchboard”
Clients ask for a service by name; a broker finds a server that offers it and connects them.
- Avoid
- A single broker
- Stale registrations
- Hidden latency
Scale and decentralisation
Space-based
“Gate checkers with a shared radio list”
Copies of the app serve everything from replicated memory; the database catches up later.
- Avoid
- Data that doesn't fit in memory
- Ignoring the write-behind window
- Conflicting writes
Peer-to-peer
“Village news over the fence”
Every peer is both client and server; information spreads peer to peer until everyone agrees.
- Avoid
- No versions or clocks
- Trusting every peer
- Expecting instant agreement
Cell-based
“Watertight compartments”
Many complete copies of the system, each serving a slice of customers, so a failure floods one compartment, not the ship.
- Avoid
- Shared dependencies between cells
- A fat router
- Cells too large
Putting it together
Choosing and combining styles
“Pick for the forces, mix by level”
Choose each style for the characteristics it serves, and use different styles at different levels of the same system.
- Avoid
- Copying a famous company
- One style for everything
- Treating a scoring table as an answer