Module 11 10 lessons 126 min
Microservices
Forty engineers work in one codebase, and every release waits for every team. The app is split into order, payment, restaurant and rider services, and function calls become network calls.
In this module
9 Read · 1 Lab
- 11.1Service boundariesSplit by business capability, not by table. Each service owns its data, and other services don't read its database.Read12 min
- 11.2Synchronous vs asynchronous callsUse a direct call when you need the answer before replying, and a queue when you don't. Payment needs an answer; sending an SMS doesn't.Read12 min
- 11.3REST vs gRPCREST and JSON for public APIs, gRPC with a shared schema between services, and the tradeoffs of each.Read12 min
- 11.4API gateway and service discoveryA single entry point for the apps, and how services find each other when instances are added and removed.Read10 min
- 11.5Backend for frontendThe customer app, the restaurant tablet and the rider app need different data. A separate backend for each client, and when one gateway is enough.Read10 min
- 11.6Aggregating data from several servicesThe order page needs data from the order, restaurant and rider services. Call them in parallel, combine the results, and decide what to return when one of them fails.Read10 min
- 11.7Authentication across servicesThe auth service signs a JWT with its private key (RS256), and every other service checks it with the public key from a JWKS endpoint - no call to the auth service per request. Key rotation, and how services authenticate each other.Read12 min
- 11.8Distributed tracingPass one request ID through every call, and use traces to find which service made an order slow.Read10 min
- 11.9Proof: one process vs five servicesPlace an order in one process, then across five services. Compare latency and find the slow call in the trace.Read8 min
- 11.10Lab: Split the order flowDesign the services for ordering, payment and dispatch, and choose how each pair communicates.Lab30 min