Microservices (Deep Workflow)
Microservices trade code simplicity for operational and contract complexity. Justify each boundary with ownership and data isolation—not fashion.
When to Offer This Workflow
Trigger conditions:
- Splitting the monolith; coupling blocks independent deploys
- Latency cascades, partial failures, contract breaks
- Conway’s law alignment between teams and services
Initial offer:
Use six stages: (1) goals & constraints, (2) boundaries & data ownership, (3) integration patterns, (4) contracts & versioning, (5) reliability patterns, (6) ops & governance). Confirm org maturity and platform capabilities.
Stage 1: Goals & Constraints
Goal: Why not a modular monolith first?
Valid drivers
- Independent deploy cadence per team
- Different scaling profiles or stacks
- Clear domain ownership and blast-radius isolation
Costs
- Distributed transactions, harder debugging, broader test matrix
Exit condition: Explicit assumption that modular monolith was considered.
Stage 2: Boundaries & Data Ownership
Goal: One service owns each aggregate’s write path; no shared writable tables across services.
Practices
- Bounded contexts from DDD when helpful
Exit condition: Entity → owning service map.
Stage 3: Integration Patterns
Goal: Sync HTTP/gRPC vs async events—match consistency needs.
Patterns
- Sagas or outbox for multi-step business processes
Exit condition: Sequence diagrams for top three flows.
Stage 4: Contracts & Versioning
Goal: Backward-compatible evolution; consumer-driven contracts optional.
Practices
- Deprecation policy published
Stage 5: Reliability Patterns
Goal: Timeouts, retries with backoff, circuit breakers, bulkheads; idempotent handlers for retries.
Stage 6: Ops & Governance
Goal: Service catalog, SLIs on dependency edges, golden paths for new services.
Final Review Checklist
- Boundary and data ownership clear
- Integration style matches consistency needs
- Contract versioning policy exists
- Reliability patterns applied at boundaries
- Ops ownership and catalog in place
Tips for Effective Guidance
- Microservices without delivery maturity often fail—say so explicitly.
- Shared databases are hidden coupling—flag them.
- The network is not reliable—design for partial failure.
Handling Deviations
- Small teams: strong bias toward modular monolith or few services.