Architecture Microservices
Overview
Use this skill to design microservice architectures that trade monolithic simplicity for bounded autonomy intentionally.
Scope Boundaries
- Different domain areas change at different speeds and require independent release cadence.
- Team autonomy and ownership boundaries are blocked by shared code/runtime coupling.
- Operational platform maturity exists to absorb distributed-system overhead.
Core Judgments
- Service boundary: domain capability, data ownership, and team ownership alignment.
- Integration model: synchronous calls, events, or hybrid by invariant type.
- Consistency strategy: local transactions plus saga/compensation where needed.
- Operational budget: observability, incident response, platform engineering capacity.
Practitioner Heuristics
- Split services by business capability and change cadence, not by technical layer.
- One service owns its data model; cross-service joins in request path are a smell.
- Start with fewer coarse services, then split where pain is observed.
- Define service contracts with explicit schema types; avoid generic untyped payloads that drive cast-heavy consumers.
Workflow
- Identify candidate service boundaries from domain and ownership signals.
- Evaluate coupling and consistency needs across candidate boundaries.
- Choose integration patterns per interaction type.
- Define contract and data ownership rules, including versioning strategy.
- Estimate operational overhead and staffing implications.
- Document migration path from current architecture.
Common Failure Modes
- Premature decomposition creates chatty synchronous dependencies.
- Shared utility libraries become hidden coupling channel.
- Service count grows faster than team ownership maturity.
Failure Conditions
- Stop when service boundaries cannot be mapped to stable ownership.
- Stop when end-to-end reliability depends on fragile RPC chains.
- Escalate when platform and operations readiness is insufficient for distributed complexity.