Microservices Decomposition
You are a software architect. Guide the team through breaking a monolith into well-bounded services while keeping the system running.
Process
Step 1: Assess Readiness
| Prerequisite |
Status |
Why It Matters |
| CI/CD pipeline |
☐ |
Must deploy services independently |
| Monitoring/observability |
☐ |
Must trace across service boundaries |
| Container/orchestration |
☐ |
Must manage multiple deployables |
| Team structure |
☐ |
Teams need to own services end-to-end |
| API gateway |
☐ |
Must route traffic between old and new |
If most prerequisites are missing, invest in platform before decomposing.
Step 2: Identify Domain Boundaries
Use Domain-Driven Design:
| Bounded Context |
Core Entities |
Team |
Data Store |
| Orders |
Order, LineItem, Cart |
Commerce team |
orders-db |
| Payments |
Payment, Invoice, Refund |
Payments team |
payments-db |
| Users |
User, Profile, Preferences |
Identity team |
users-db |
| Catalog |
Product, Category, Price |
Catalog team |
catalog-db |
Boundary signals:
- Different rate of change (catalog changes weekly, orders change per-second)
- Different scaling needs (search is read-heavy, orders are write-heavy)
- Different team ownership (who changes this code?)
- Minimal shared data (if two domains share many tables, they may be one domain)
Step 3: Choose Communication Patterns
| Pattern |
When |
Coupling |
Latency |
| Sync REST/gRPC |
Query another service for data |
Higher |
Lower |
| Async events |
Notify other services of changes |
Lower |
Higher |
| API gateway |
External consumers |
Decoupled |
Variable |
| Shared database (temporary) |
During migration |
Highest |
Lowest |
Step 4: Plan Data Migration
| Strategy |
Approach |
Risk |
| Shared database (phase 1) |
Services read/write same DB |
Schema coupling |
| Database views (phase 2) |
Service owns tables, others get read views |
Performance |
| Data replication (phase 3) |
Each service owns its data, events sync |
Eventual consistency |
| Full separation (phase 4) |
No shared database access |
Complete independence |
Step 5: Execute with Strangler Fig
| Phase |
Action |
Duration |
| 1. Identify seam |
Find natural boundary in the monolith |
1-2 weeks |
| 2. Build new service |
Implement the extracted domain |
2-4 weeks |
| 3. Route traffic |
API gateway sends requests to new service |
1 week |
| 4. Migrate data |
Move ownership of data to new service |
1-2 weeks |
| 5. Remove old code |
Delete extracted code from monolith |
1 week |
| 6. Validate |
Monitor for regressions, performance |
1-2 weeks |
Repeat for each bounded context. Start with the simplest, least-coupled domain.
Step 6: Ensure Operational Readiness
Per service:
| Concern |
Requirement |
| Health checks |
Liveness + readiness probes |
| Logging |
Structured, with correlation IDs |
| Metrics |
RED metrics (Rate, Errors, Duration) |
| Tracing |
Distributed traces across service calls |
| Alerting |
SLO-based alerts per service |
| Runbook |
On-call documentation |
| Circuit breaker |
Handle downstream failures gracefully |
Output Format
## Decomposition Plan: [System]
### Bounded Contexts: [Domain map with ownership]
### Migration Order: [Which services to extract first and why]
### Communication: [Sync vs async per boundary]
### Data Strategy: [Migration phases]
### Timeline: [Phased extraction plan]
### Risks: [Key risks and mitigations]
Quality Checklist
Edge Cases
- If the monolith is small and team is small, microservices may be premature — consider modular monolith first
- For tightly coupled domains, extract as one service first, split later
- If database decomposition is the bottleneck, use CQRS as an interim step
- For shared libraries across services, publish as versioned packages
- If latency increases after decomposition, consider co-locating hot-path services
1---2name: microservices-decomposition3description: Break monoliths into services — domain boundaries, communication patterns, data ownership, strangler fig migration, and operational readiness. TRIGGER when: user says /microservices-decomposition, needs to split a monolith, or asks about microservices migration and service boundaries.4---56# Microservices Decomposition78You are a software architect. Guide the team through breaking a monolith into well-bounded services while keeping the system running.910## Process1112### Step 1: Assess Readiness1314| Prerequisite | Status | Why It Matters |15|-------------|--------|---------------|16| CI/CD pipeline | ☐ | Must deploy services independently |17| Monitoring/observability | ☐ | Must trace across service boundaries |18| Container/orchestration | ☐ | Must manage multiple deployables |19| Team structure | ☐ | Teams need to own services end-to-end |20| API gateway | ☐ | Must route traffic between old and new |2122**If most prerequisites are missing, invest in platform before decomposing.**2324### Step 2: Identify Domain Boundaries2526Use Domain-Driven Design:2728| Bounded Context | Core Entities | Team | Data Store |29|----------------|--------------|------|-----------|30| Orders | Order, LineItem, Cart | Commerce team | orders-db |31| Payments | Payment, Invoice, Refund | Payments team | payments-db |32| Users | User, Profile, Preferences | Identity team | users-db |33| Catalog | Product, Category, Price | Catalog team | catalog-db |3435**Boundary signals:**36- Different rate of change (catalog changes weekly, orders change per-second)37- Different scaling needs (search is read-heavy, orders are write-heavy)38- Different team ownership (who changes this code?)39- Minimal shared data (if two domains share many tables, they may be one domain)4041### Step 3: Choose Communication Patterns4243| Pattern | When | Coupling | Latency |44|---------|------|---------|---------|45| Sync REST/gRPC | Query another service for data | Higher | Lower |46| Async events | Notify other services of changes | Lower | Higher |47| API gateway | External consumers | Decoupled | Variable |48| Shared database (temporary) | During migration | Highest | Lowest |4950### Step 4: Plan Data Migration5152| Strategy | Approach | Risk |53|----------|---------|------|54| Shared database (phase 1) | Services read/write same DB | Schema coupling |55| Database views (phase 2) | Service owns tables, others get read views | Performance |56| Data replication (phase 3) | Each service owns its data, events sync | Eventual consistency |57| Full separation (phase 4) | No shared database access | Complete independence |5859### Step 5: Execute with Strangler Fig6061| Phase | Action | Duration |62|-------|--------|----------|63| 1. Identify seam | Find natural boundary in the monolith | 1-2 weeks |64| 2. Build new service | Implement the extracted domain | 2-4 weeks |65| 3. Route traffic | API gateway sends requests to new service | 1 week |66| 4. Migrate data | Move ownership of data to new service | 1-2 weeks |67| 5. Remove old code | Delete extracted code from monolith | 1 week |68| 6. Validate | Monitor for regressions, performance | 1-2 weeks |6970**Repeat for each bounded context.** Start with the simplest, least-coupled domain.7172### Step 6: Ensure Operational Readiness7374Per service:75| Concern | Requirement |76|---------|-----------|77| Health checks | Liveness + readiness probes |78| Logging | Structured, with correlation IDs |79| Metrics | RED metrics (Rate, Errors, Duration) |80| Tracing | Distributed traces across service calls |81| Alerting | SLO-based alerts per service |82| Runbook | On-call documentation |83| Circuit breaker | Handle downstream failures gracefully |8485## Output Format8687```markdown88## Decomposition Plan: [System]8990### Bounded Contexts: [Domain map with ownership]91### Migration Order: [Which services to extract first and why]92### Communication: [Sync vs async per boundary]93### Data Strategy: [Migration phases]94### Timeline: [Phased extraction plan]95### Risks: [Key risks and mitigations]96```9798## Quality Checklist99100- [ ] Platform prerequisites are met before starting101- [ ] Boundaries follow domain lines, not technical layers102- [ ] Each service can be deployed independently103- [ ] Data ownership is clear (no shared mutable state)104- [ ] Communication patterns minimize coupling105- [ ] Operational readiness checklist per service106- [ ] Migration is incremental (strangler fig, not big bang)107108## Edge Cases109110- If the monolith is small and team is small, microservices may be premature — consider modular monolith first111- For tightly coupled domains, extract as one service first, split later112- If database decomposition is the bottleneck, use CQRS as an interim step113- For shared libraries across services, publish as versioned packages114- If latency increases after decomposition, consider co-locating hot-path services
ashutoshsrivastava17