Quiz
Warm-up from unit 2: your app runs as 8 identical stateless copies behind a load balancer. Is that microservices?
Two ways to organize the same code
A monolith is one program containing all your features: auth, payments, feed, search, one codebase, one deploy. Everything we built in units 1 through 7 works perfectly with a monolith.
Microservices split those features into separate programs, each with its own deploys and often its own database, talking to each other over the network.
What microservices genuinely buy:
- Independent deploys: the payments team ships without waiting for the feed team
- Independent scaling: run 40 copies of the hot service, 2 of the quiet one
- Failure isolation: a crash in search does not take down checkout
What they genuinely cost:
- Every in-process function call becomes a network call: slower, and it can fail (the How the Internet Works lesson again)
- Debugging spans machines, testing needs many services running
- Data is split, so no joins across services and no single transaction
The honest rule: microservices solve an organizational problem, too many engineers stepping on one codebase. Under about 20 engineers, a well-factored monolith is almost always the better system.
Code exercise · python
Run this latency comparison. A function call inside one process costs about a microsecond. A call between services in the same data center costs about 2 ms. Chain 5 of them and compare.
API contracts between services
Once features live in separate services, the request and response formats between them become contracts: agreements that other teams' code depends on.
The cardinal rule is backward compatibility. The feed service cannot rename a field in its response on Tuesday, because the three services reading that field would break instantly. Safe changes add optional fields. Breaking changes require a versioned API (/v1/feed, /v2/feed), running both versions while every caller migrates.
Teams write contracts down in machine-readable form, OpenAPI specs for HTTP APIs or protobuf schemas for gRPC, so both sides can generate code and catch mismatches before deploy. When an interviewer asks how services communicate, naming the contract and its versioning story is what separates a real answer from a hand wave.
Quiz
The orders service wants to rename the field "total" to "total_cents" in its API response. Four other services read "total" today. What is the safe migration?