Service Boundaries
1 min read
Draw boundaries so each service owns its data and communicates through APIs, not shared DBs.
Each service owns its data store. Communicate through APIs and events, never through shared databases.
How It Works
Service boundaries define what each component owns and how components communicate. The golden rule: each service owns its data store — no shared databases. Communication patterns: synchronous (REST/gRPC), asynchronous (message queue — see Queues), event-driven (pub/sub). Justify why you drew a boundary where you did.
Real-World Example
In e-commerce, Order Service and Inventory Service have a service boundary. When an order is placed, Order Service publishes an OrderCreated event. Inventory Service subscribes, decrements stock, and publishes InventoryReserved. This saga pattern maintains consistency without a shared database.
Test Yourself
Scenario: An e-commerce monolith (50 engineers, single Postgres DB) is being split into services. Where do you draw the boundaries, and what is the hard rule that tells you when two things are really one service?
Get notified when we launch
One email when the full practice product is live. No spam.