AR2: Architecture styles: monoliths, modular monoliths, microservices and events
The monolith
🎯You'll be able to
Describe a monolith, explain why it's often the right start, and recognise when one is becoming hard to change.
🏠The everyday picture
A family-run restaurant has one kitchen where everyone cooks everything. It's simple and fast while the menu is small. When the menu triples, cooks bump into each other and one burnt pan stops the whole service.
📘What it really is
- A monolith is one application, built and deployed as one unit, usually with one database. All its parts run in one process.
-
Its strengths: one thing to build, test, deploy and debug; function calls instead of network calls; one transaction can update orders, payments and invoices together.
-
It's a sound default for a new product and a small team. Many large, successful systems still run as monoliths.
-
Warning signs that it's getting hard to change: every deploy ships everything and is risky; a failure in one part stops others; teams wait for each other; parts reach into each other's data.
-
These are coupling problems, not size problems. A big monolith with clear boundaries can be easier to change than many small, tangled services.
📝A worked example
Input: RasoiRoute's figures and the starter's npm run deps.
Steps:
- Deploys: 1.5 a week, 22.2% rolled back, every one shipping all modules.
- Failures: 42.3% of incidents start in notifications, and orders wait for messages.
- Coupling: 5 internal reaches and one cycle joining orders, invoices and notifications.
- Team: 14 engineers in 3 teams, a size many monoliths serve well.
Expected output: the problems are risky deploys, a failure that spreads, and tangled modules, not the size of the code or the team.
🌍Where it's used
- Early-stage start-ups launch on a monolith so they can change direction quickly.
- Internal business tools often stay monoliths for their whole life.
- Large platforms such as some well-known code-hosting and e-commerce sites have run large monoliths with many engineers.
📝Case scenario
A payments start-up began with microservices because "that's how big companies do it". With six engineers and eleven services, half of each week went on deploys, monitoring and debugging calls between services. They merged back into one well-structured application and shipped faster.
🖱️Try it
Pick a system you know and list its warning signs from the list above. Success: each sign has evidence, not a feeling.
⚠️Common mistakes
- "Monolith" as an insult. Sign: wanting to split because the word sounds old. Fix: look for the warning signs with evidence.
- Blaming size for coupling. Sign: "it's too big" when the real issue is parts reaching into each other. Fix: measure coupling.
- Ignoring deploy pain. Sign: deploys only at night, by one person. Fix: count deploy frequency and rollbacks.
🛠️For your project
Project 1's first option is "keep the monolith as it is". Score it fairly: it has real strengths (test 3 asks for good and bad points).
✅Quick check
What is a monolith?
Show the answer
One application built and deployed as a single unit, with all its parts in one process.
Why can a monolith be the right choice?
Show the answer
It's simpler to build, test, deploy and debug, and one transaction can update several parts together.