Service Boundaries
Learn how to split responsibilities across services without creating accidental distributed complexity.
What you will be able to do
A service boundary decides who owns behavior and data. Good boundaries reduce coordination. Bad boundaries create network calls, duplicate logic, unclear ownership, and harder incidents.
What Is a Service Boundary?
A service boundary is the line around a responsibility: what the service owns, what data it controls, what API it exposes, what it promises, and what it refuses to know.
| Boundary signal | What it means | Example |
|---|---|---|
| Business capability | A clear product responsibility | Payments owns charges, refunds, receipts. |
| Data ownership | One service is source of truth | Catalog owns product title and price version. |
| Change rate | Parts change independently | Recommendation ranking changes faster than billing rules. |
| Scale profile | Traffic patterns differ | Search reads scale differently from order writes. |
| Reliability need | Failure impact differs | Payment correctness matters more than marketing email delivery. |
Scenario: Ecommerce Platform
An ecommerce system may include catalog, cart, checkout, payment, inventory, notification, search, and analytics. Splitting all of them into services on day one is not automatically professional. The right boundary depends on ownership, scale, data consistency, and operational maturity.
| Capability | Possible owner | Boundary concern |
|---|---|---|
| Catalog | Catalog service or module | Product data changes often and powers browsing/search. |
| Cart | Cart service or module | Needs low-latency user-specific state. |
| Checkout | Checkout orchestrator | Coordinates order creation and payment intent. |
| Payment | Payment service | High correctness, audit, provider integration. |
| Inventory | Inventory service | Consistency required for scarce items. |
| Notification | Notification service | Async retries and provider failures. |
Modular Monolith vs Services
A modular monolith can be an excellent architecture when the team is small and the domain is still changing. Services become useful when independent ownership, deployment, scale, or reliability needs justify the operational cost.
| Option | Use when | Risk |
|---|---|---|
| Modular monolith | One team, early product, shared deployment acceptable | Can decay into tangled code without internal boundaries. |
| Few coarse services | Clear capabilities and separate scale/reliability needs | Requires API contracts and operational maturity. |
| Many microservices | Many teams own mature domains independently | Network failures, distributed debugging, and data consistency complexity. |
Design principle
Do not split services to look advanced. Split when the boundary reduces product, data, scaling, deployment, or ownership complexity more than it adds operational complexity.
Data Ownership
The hardest part of service boundaries is data. If two services write the same table, ownership is unclear. If every service needs a synchronous call to complete basic work, the boundary may be too fine.
| Rule | Why |
|---|---|
| One source of truth per business entity | Avoids conflicting updates and unclear ownership. |
| Expose data through API or events, not shared writable tables | Keeps boundaries enforceable. |
| Avoid distributed transactions when possible | They increase failure and coordination complexity. |
| Duplicate read models deliberately | Denormalized views can improve reads if ownership is clear. |
| Use events for state changes other services need to know | Reduces direct coupling when immediate response is not required. |
Cloud Deployment Options
| Architecture style | AWS | GCP | Azure |
|---|---|---|---|
| Modular monolith container | ECS/EKS | Cloud Run/GKE | Container Apps/AKS |
| Independent services | ECS services/EKS deployments/Lambda | Cloud Run services/GKE deployments/Functions | Container Apps/AKS/Functions |
| Service-to-service routing | ALB/API Gateway/App Mesh | Cloud Load Balancing/Service Mesh | Application Gateway/API Management/Service Mesh |
| Events between services | SNS/EventBridge/SQS | Pub/Sub/Eventarc/Cloud Tasks | Event Grid/Service Bus |
| Secrets/config | Secrets Manager/Parameter Store | Secret Manager | Key Vault/App Configuration |
Boundary Review Questions
- Who owns this behavior when it breaks?
- Which service is source of truth for this data?
- Does this boundary reduce or increase the number of synchronous calls?
- Can this part deploy independently without forcing many clients to change?
- Does this part have a different scale, reliability, or compliance need?
Beginner Mistakes
- Splitting into microservices before the product domain is understood.
- Letting multiple services write the same data directly.
- Creating chatty synchronous calls between tiny services.
- Treating team structure as irrelevant to architecture.
- Ignoring how logs, metrics, tracing, and deployments become harder with more services.
Guided Practice
Practice task
For a food delivery product, propose boundaries for restaurant menu, order, payment, rider location, and notification. State which one should probably be async.
Sample Answer
| Capability | Boundary decision |
|---|---|
| Restaurant menu | Catalog/menu owner because menus change independently and power browsing. |
| Order | Order owner because order state transitions are core product truth. |
| Payment | Separate payment boundary because correctness, audit, provider integration, and compliance matter. |
| Rider location | Separate high-write location stream/read model because scale profile differs. |
| Notification | Async notification boundary because delivery can retry and provider outages should not break order creation. |
Before You Continue
- You should know what a service boundary owns.
- You should understand why data ownership matters.
- You should be able to argue for a monolith, coarse services, or microservices.
- You should be ready to choose synchronous or asynchronous communication between boundaries.