Service Boundaries
Drawing lines along change patterns rather than technical layers.
6 to work through
-
intermediate Multiple choice
For a retailer, should order management, payment and fulfilment be one service or three?
2 min answer -
intermediate
Two services share a database because it was faster to build that way. Both teams now block each other on every schema change. What do you do?
1 min answer -
advanced
A team is splitting a service and discovers the split would break a transaction. What are the options, and which is usually right?
2 min answer -
advanced Multiple choice
A team proposes extracting a service. What single test best predicts whether the boundary is right?
2 min answer -
advanced
A team split a monolith into 14 services. Every feature now touches 4 or 5 of them, and releases are coordinated weekly. What would you change?
2 min answer -
advanced
Netflix moved from a very large number of fine-grained microservices toward fewer, better-bounded services. What signals indicate that service boundaries are wrong, and how would you execute a consolidation safely?
2 min answer
6 terms in this topic
Boundary Reversal Asymmetry
The fact that a boundary drawn too coarse is cheap to split later while one drawn too fine is expensive to merge, which makes the coarse error the ri…
practiceBoundary Volatility Test
Evaluating a proposed service boundary by asking whether the things on either side change for different reasons and at different rates.
practiceCo-Change Analysis
Using version-control history to find which components change together - the strongest available evidence that a proposed boundary is right or wrong.
case-studyDoorDash: Decomposing a Python Monolith
DoorDash moved off a Python monolith as growth made deployment risk and scaling limits unmanageable, and used a facade to migrate incrementally.
conceptInvariant Containment
The rule that a service boundary must contain any invariant that must hold exactly - so discovering that a split would break a transaction is evidenc…
practiceService Boundary Heuristics
The signals that indicate where a service boundary belongs, and the ones that reliably mislead.
Neighbouring topics
Software Architecture
General material on the engineering underneath an architecture.
SOLID
Five design principles, two of which scale beyond the class.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Bounded Contexts
Where one model ends and another begins, and why forcing one fails.
Clean Architecture
Concentric layers with dependencies pointing only inwards.
Hexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
Microservices
Independent deployability, and the distributed problems it buys.
Modular Monolith
Enforced internal boundaries without a network between them.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Refactoring
Changing structure without changing behaviour, in verified steps.
Technical Debt
Deliberate, tracked and repaid — as distinct from mess.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Contract Tests
Capturing what consumers actually use, not what the API documents.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Feature Flags
Decoupling deploy from release, with an expiry date.
Trunk-Based Development
Short-lived branches, and unmerged work as inventory.
Code Review
Where architectural rules are enforced by people rather than by tools.
DORA Metrics
Throughput and stability moving together rather than trading off.