Monoliths and microservices
See what microservices are, what they cost, and when a well-built monolith is the better choice.
- Define a microservice and contrast it with a monolith and a modular monolith
- Weigh the benefits - independent deploys and scaling, team autonomy - against the costs
- Explain Conway’s law and why architecture follows team structure
Welcome to Galactic Noodle Express: hot ramen delivered anywhere in the solar system by tiny rockets. It started as one app - NoodleMonolith - that handles menus, orders, payments, the kitchen and rocket dispatch. It worked beautifully... until there were 60 engineers in one codebase, a 45-minute build, and a rule that nobody deploys on Fridays because a typo in the menu code once grounded every rocket.
The company wants to move to microservices. Your job, over this track, is to help do it well - and to know when not to.
What is a microservice?
A microservice is a small, independently deployable service that owns one business capability - and its own data - and talks to other services only over the network, through well-defined APIs or events. A monolith packages all capabilities into one deployable unit.
| Monolith | Microservices | |
|---|---|---|
| Deploy | everything at once | each service on its own schedule |
| Scale | the whole app | just the busy services (the kitchen on Friday night) |
| Failure | one bug can take down everything | failures can be contained - or can cascade if you’re careless |
| Data | one shared database | each service owns its data |
| Calls between parts | in-process function calls: fast, reliable | network calls: slow, can fail, need retries and timeouts |
| Consistency | database transactions | eventual consistency, sagas |
| Operations | one thing to run, log and debug | dozens of things to deploy, monitor and trace |
| Teams | everyone coordinates | small teams own services end to end |
Try it
Is it worth splitting?
For each situation, would microservices likely help, or would a (modular) monolith serve better?
“A 4-person startup still searching for product-market fit”
“80 engineers in 9 teams, constantly blocked waiting for each other’s deploys”
“Image processing needs 50 GPU machines; the rest of the app needs two small servers”
““Microservices are modern” - no other reason”
“An internal tool used by 20 people, maintained by one developer”
“The payment code needs stricter security and audits than the rest of the system”
Blast radius
One promise of microservices is that a failure stays contained. Whether it does depends on the dependency graph: if service A calls B synchronously and B is down, A is in trouble too - and so is everything that calls A. Here’s Galactic Noodle Express’s first draft:
1calls = {
2 "gateway": ["orders", "menu"],
3 "orders": ["payments", "kitchen", "menu"],
4 "kitchen": ["inventory"],
5 "delivery": ["orders"],
6 "menu": [],
7 "payments": [],
8 "inventory": [],
9}
10
11def affected_by(down):
12 affected = set()
13 changed = True
14 while changed:
15 changed = False
16 for service, dependencies in calls.items():
17 if service not in affected and (down in dependencies or affected & set(dependencies)):
18 affected.add(service)
19 changed = True
20 return sorted(affected)
21
22print("inventory down ->", affected_by("inventory"))
23print("menu down ->", affected_by("menu"))inventory down -> ['delivery', 'gateway', 'kitchen', 'orders'] menu down -> ['delivery', 'gateway', 'orders']
If inventory goes down, four services are affected - nearly the whole system. Later lessons shrink that blast radius with asynchronous events, timeouts, fallbacks and circuit breakers.
Key takeaways
A microservice is independently deployable, owns one business capability and its data, and talks over the network.
Benefits: independent deploys, scaling and team ownership. Costs: network calls, eventual consistency, operational complexity.
A modular monolith is often the right start; split when there’s a clear reason.
Conway’s law: align service boundaries with team boundaries.
Lesson quiz
7 questions · pass with 5 correct · up to 50 XP
Passing this quiz completes the lesson and keeps your streak going. Questions you miss come back in review sessions later.
Practice: simulate microservice patterns in Python
Build small Python simulations of the patterns - routers, sagas, outboxes, circuit breakers, traces - and run them against sample inputs. They run locally in your browser; no servers or containers needed.
Blast radius
Each input line is service: dependency dependency ... (the services it calls synchronously; a service may have none). The last line is down: NAME. Print the services affected by that outage - those that call it directly or through other services - sorted, as affected: a, b, then unaffected: ... (everything else except the down service), using none for an empty list.
- Inventory down
- A leaf service
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Coordinated releases
A good boundary lets most features ship by changing one service. The input has module -> service lines, a line ---, then features as feature: module module ... (the modules it changes). For each feature print the services it touches, sorted, and whether it ships alone or needs a coordinated release. Finally print independent: 2 of 3 features (67%), rounding to a whole percentage.
- First draft boundaries
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Questions about this lesson
Stuck? Ask. Figured something out? Share it. Explaining is one of the best ways to learn.
Loading posts…