When starting a new system, what should drive the choice of architectural style (layered monolith, modular monolith, microservices, event-driven, and so on) — and what should not?
answer
- characteristics + constraints, not fashion
- pick top ~3, accept mediocrity elsewhere
- measurable targets, not adjectives
- simplest style that hits the targets
- record in ADR with rejected options
basics
~20 sChoose from the qualities the system must have (scale, availability, speed of change, cost) plus its constraints (team size, skills, deadline, budget, regulation). Do not choose by fashion, resume value, or what a famous company uses.
solid answer
~40 sA style is selected from architecture characteristics (quality attributes) and constraints, not popularity. Method: collect the business drivers, translate them into a short ranked list of characteristics — realistically two or three, because they conflict — then ask which styles naturally supply them. Microservices buy independent deployability, fault isolation and per-service scaling, and pay in network failure, eventual consistency, costly testing and observability. A modular monolith buys simplicity, single-database transactions and cheap refactoring, but deploys and scales as one unit. Event-driven buys throughput and decoupling, and pays in debugging and workflow visibility. Constraints then eliminate candidates: a four-person team with no platform engineers cannot operate forty services; a data-residency rule may force partitioning. Finish with an ADR recording the decision, rejected alternatives and what was traded away, so the choice can be revisited deliberately.
go deeper
Say the choice comes from what the system must be good at plus real constraints like team size and deadline, and name one concrete trade-off, for example that microservices deploy independently but are harder to test.
Show the loop: drivers to measurable characteristics, rank the top three, eliminate by constraints, score candidates. Contrast at least two styles on deployability, testability and cost.
Emphasise that characteristics conflict, that you deliberately accept weakness outside the top three, and that boundaries and reversibility matter as much as the initial pick. Mention ADRs and fitness functions.
Frame it as risk and option management across the organisation: which decisions are reversible, which are one-way doors, how team topology and funding shape feasible styles, and what evidence would trigger re-evaluation.
### Terms **Architectural style** is the top-level shape of a system: how it is divided, how the parts talk, how they deploy. - **Layered monolith** — one deployable unit split into technical layers (UI, business logic, data access). Cheap, simple, easy to test end to end; everything ships together. - **Modular monolith** — one deployable unit split by business capability with enforced internal boundaries. Keeps simplicity and transactions, buys clean seams for later extraction. - **Microservices** — many independently deployable services, each owning its own data. - **Event-driven** — components communicate asynchronously through events or messages rather than direct calls. - **Pipeline / batch** — data flows through stages; ideal for transformation workloads. **Architecture characteristics** (also called quality attributes, non-functional requirements, or "-ilities"): scalability, elasticity, availability, fault tolerance, deployability, testability, performance, security, evolvability, simplicity, cost. **Constraints** are non-negotiable givens: team size and skill, budget, deadline, existing platform, compliance, contracts. ### Why requirements alone do not decide Functional requirements ("users can place an order") can be met by almost any style. What differs is *how well* the system does everything else. So the selection input is the characteristics, ranked. Ranking matters because characteristics conflict: elasticity fights simplicity, performance often fights evolvability, strong consistency fights availability under a network partition. Trying to maximise everything yields an over-engineered system that is good at nothing. A practical rule is to pick roughly the top three drivers and consciously accept mediocrity elsewhere. ### The selection loop 1. Extract business drivers (growth forecast, uptime promise, release cadence, regulatory scope, budget). 2. Translate each into a characteristic with a *measurable* target: not "fast" but "p99 under 200 ms at 5,000 requests per second". 3. Rank them; keep the top two or three explicit. 4. Apply constraints to eliminate infeasible styles outright. 5. Score the surviving candidates against the ranked characteristics. 6. Prefer the simplest style that meets the targets, keeping seams where change is likely. 7. Record it in an Architecture Decision Record, including the discarded options and the trigger that would make you revisit. ### Edge cases Greenfield work with unknown domain boundaries argues for a modular monolith — boundaries are cheap to move inside one process and expensive to move across a network. A system whose load is spiky and whose parts scale very differently argues for splitting earlier. A hard organisational constraint (three autonomous teams that must ship independently) can justify service boundaries even when the technical case is weak. And a "non-requirement" is valuable information: if the business genuinely tolerates an hour of downtime, do not pay for multi-region active-active.
- Why is it usually advised to pick only about three top architecture characteristics?Because they conflict — elasticity fights simplicity, availability fights strong consistency, performance fights evolvability. Optimising for everything produces cost and complexity with no clear strength, and leaves the team no tie-breaker when a design decision forces a choice.
- How do you make a characteristic like 'scalable' usable in a decision?Make it measurable and time-bounded: 'sustain 5,000 requests per second with p99 under 200 ms, growing fourfold within 18 months'. That turns a slogan into a threshold you can test candidate styles against and later verify with an automated fitness function.
Choosing a vehicle: a cargo ship, a van and a motorbike all move goods. You decide by volume, deadline, route and the licence you hold — not by which one looks most impressive parked outside the office.
saying these in an interview costs you the question
- 'We'll use microservices because that's the modern way' — style chosen by fashion, not by drivers
- Listing ten equally important characteristics, which means nothing is actually prioritised
- Treating functional requirements as the deciding input; they rarely discriminate between styles
- Ignoring team size and operational maturity as first-class constraints
- Assuming the choice is permanent and therefore must be perfect on day one