Software Architectures
Architecture is the set of decisions that are expensive to change. Pick the style that matches your team size, your deployment cadence, and the rate at which the business demands new features.
Monolith
One codebase, one deployable, one process. The default. Fastest to build, cheapest to run, simplest to reason about. Don't apologise for shipping one — most successful companies were monoliths for years.
Watch-outs: shared database makes coupling implicit, deploys touch everything, a single memory leak takes down the world. Solution: modular monolith — strict module boundaries inside one process, so you can split later if you must.
See Monolith Architecture (sub-deck).
N-tier
Layers stacked by responsibility: presentation, business, data. Most enterprise apps of the 2000s. Discipline through layering; communication only downward.
Watch-outs: "anaemic domain model" — the business layer becomes a thin pass-through because logic leaks into the presentation or data layer.
See N-tier Architecture (sub-deck).
Hexagonal (ports & adapters)
The domain sits at the centre. Ports are interfaces it exposes
(OrderRepository, EmailSender). Adapters are the
concrete implementations (Postgres, SES, REST handler). The domain knows nothing about
web, database, or message queue.
Why it matters: you can replace the database, swap the web framework, or test the business rules without a server or a DB. The dependency arrow points inward, always.
See Hexagonal Architecture (sub-deck).
Microservices
Each bounded context is a separate service with its own process, database, and deploy. Communication via HTTP, gRPC, or async messaging.
Benefits: independent deploys, independent scaling, independent failure. Costs: distributed-system problems become your daily reality — eventual consistency, network failure, observability across services, schema evolution.
Rule: don't start with microservices. Reach for them when you can name a specific organisational or scaling pain a monolith causes you today.
See Microservices Architecture (sub-deck).
Picking among them
The honest decision tree:
- Team < 10 engineers, < 100k users: modular monolith. Stop reading.
- Team 10–50, predictable traffic: N-tier or hex monolith.
- Team 50+, independent product lines, conflicting deploy schedules: extract microservices one at a time. Never big-bang.
"If you can't build a monolith, what makes you think microservices are the answer?" — Simon Brown.
What to remember at exam time
- Draw each style and label its components.
- One advantage and one disadvantage per style.
- Hexagonal's dependency rule: outer depends on inner; inner never imports outer.
- Microservices add operational complexity — they only pay off when their independence pays off.