What this track owns
Communication — how two endpoints talk (REST, gRPC, webhooks). Distributed Systems — correctness across nodes (CAP, consensus, sagas). This track — how you organize dozens of services: discovery, gateways, mesh, event sourcing, deployment patterns.
Bounded context (DDD)
A bounded context is a boundary within which a domain model is consistent. Order in checkout ≠ Order in fulfillment — different attributes, different lifecycle.
Microservice ≈ bounded context (ideal, not law). One team owns one context; one deployable service per context is the target.
Anti-pattern: distributed monolith — many services, shared database, synchronized deploys, chatty sync calls. You pay microservices ops cost without independence.
Decomposition heuristics
| Signal | Split candidate |
|---|---|
| Different scaling profile | Read-heavy catalog vs write-heavy ingest |
| Different release cadence | Payments vs marketing site |
| Different data shape | Graph relationships vs tabular ledger |
| Regulatory boundary | PII-heavy identity vs public API |
Split along business capability, not technical layer ("UserService", "DatabaseService").
Data ownership rule
Each service owns its data — no direct DB access from other services. Integration via API or events only.
Shared DB = hidden coupling; schema changes become multi-team coordination nightmares.
Strangler fig migration
- Put facade/gateway in front of monolith
- Route one capability to new service
- Gradually migrate reads, then writes
- Retire monolith path when traffic = 0
Staff signal: never "big bang" rewrite unless executive mandate with budget.
Integration between contexts
- Sync — when user waits (checkout total)
- Async — when eventual OK (send email, update search index)
- Shared kernel — minimize; versioned client library OK, shared DB not OK
Cross-reference: Communication for protocol choice; Distributed Systems → Transactions for saga when sync chain breaks.
Interview one-liner
"I'd split on change frequency and data ownership, not on CRUD tables. Each service owns its store and exposes a narrow contract."
Further Reading
Hands-On Tasks (Optional)
Architecture drills and whiteboard exercises. Assumes Communication & Data Transfer and Distributed Systems fundamentals.
- Draw service boundaries for e-commerce20m
Split catalog, cart, checkout, payments, inventory, notifications. For each pair, specify sync API vs async event and who owns the data. Flag one boundary you'd keep in a modular monolith first.