Choosing an architecture style
Teams often pick a style because a famous company uses it or because the last project hurt. This lesson gives you a method that starts from your quality-attribute scenarios, removes options that break a hard constraint, scores the rest with anchored evidence, and then tests how fragile the result is. You apply it to Mangrove Market's back office, where modular monolith, microservices, event-driven and serverless all have honest supporters.
By the end you can
- Describe each of the four styles by what it constrains, what it buys and what it costs
- Use knock-out constraints before any scoring, and say why a style can fail one part and fit another
- Build a weighted decision matrix with anchored 1 to 5 scores that a reviewer can check
- Run a sensitivity check that finds the weight change that would flip the decision
- Choose a style per part of the system and state the trigger that would make you revisit it
The everyday picture
A growing city has to move people. It can build a metro, run buses, add bicycle lanes or let taxis and ride apps fill the gaps. A metro carries huge crowds fast and never sits in traffic, but it takes years to build and costs a fortune to run, so no city builds one to a quiet suburb. Buses are cheap and flexible, but they get stuck in the same jams as everyone else.
Good city planners do not ask "which transport is best?". They ask what each route needs: how many people, how far, at what hours, with what budget. The busy central corridor gets the metro. The suburbs get buses. The old town's narrow lanes get bicycles. And they check the plan against the one thing that cannot change, such as "the river bridge can carry only so much weight".
Choosing an architecture style works the same way. Each style is a transport mode with a known cost profile. You match it to the needs of each part of the system, you drop any mode that breaks a hard limit, and you are suspicious of any plan that uses one mode for everything.
A style is a set of constraints you accept on purpose
An architecture style is a set of rules about which parts a system has and how they may connect. Microservices, for example, say that each service owns its data and no other service may read its tables. Following those rules gives you certain qualities for free and makes others expensive. That is the whole point: you accept the constraint to buy the quality. If you break the rules and keep the name, you pay the costs and lose the benefits.
The basics of the monolith, the modular monolith and microservices are in Monolith, modular monolith, microservices, and the outbox and sagas that event-driven systems need are in Events, the outbox pattern and sagas. Here we compare four styles side by side, by the rule each one imposes and what that rule buys and costs.
| Style | Rule you accept | What it buys | What it costs |
|---|---|---|---|
| Modular monolith | One deploy; modules talk only through public interfaces and own their tables | One transaction across modules, simple operations, fast calls | One release train; a bad module can still slow the shared process and database |
| Microservices | Each service deploys alone and owns its database | Independent releases and scaling per team; failures contained per service | Network calls, distributed data, a platform to run many services |
| Event-driven | Parts announce facts on a broker and never wait for each other | Loose coupling in time, peaks absorbed by queues, easy fan-out | Eventual consistency, harder debugging, ordering and duplicate handling |
| Serverless | Code runs as short functions on a provider's managed runtime | No servers to manage, scale to zero, pay per use | Run-time limits, cold starts, provider lock-in, cost at steady high load |
A useful unit for this comparison is the architecture quantum: a part you can deploy on its own, with its own quality-attribute needs. Ford, Parsons and Kua introduced the term in Building Evolutionary Architectures. A classic monolith is one quantum, so the whole system must meet the strictest need of any part. If goods receiving needs a p95 under 2 seconds and the month-end report needs 40 minutes of heavy reading, one quantum must satisfy both at once. That is why Mangrove's slow stock report has twice frozen receiving in the stores. Splitting into more quanta is worth it when parts have different needs that fight each other. When parts share the same needs, more quanta add cost and buy nothing.
Quick check
A team calls its system "microservices", but all eight services read and write the same stock table and must be released together. What does the team actually have?
The style's rule is "each service owns its data and deploys alone". Breaking it keeps every cost (network calls, many deploys) and loses the benefit, which is the definition of a distributed monolith. Separate repositories do not make it modular: the shared table couples every service.