| name | microservice-researcher |
| description | Guides research and analysis for microservices architecture decisions—domain decomposition,
bounded contexts, service boundary options and trade-offs, sync vs async integration patterns,
data ownership and consistency (eventual consistency, sagas at research level), API and contract
evolution, Team Topologies alignment, build vs buy vs managed services, monolith strangler
migration, NFR impact (latency, reliability, operability), and decision records with options and
recommendations. Use for microservice research, service boundaries, bounded context, strangler
fig, monolith to microservices, saga vs two-phase commit, domain decomposition, microservices
trade-off, team topologies, eventual consistency research, API versioning strategy—not assessing
an existing estate (microservices-analyst), production service code (senior-software-engineer,
platform-engineer), Kubernetes cluster ops only (cloud-engineer), pure network design
(network-backbone-architect), or EDA implementation when building not researching
|
Microservice Researcher
When to Use
- Research domain decomposition, bounded contexts, and candidate service boundaries
- Compare microservices vs modular monolith (or other styles) with explicit trade-offs
- Analyze sync vs async integration, data ownership, and consistency models at decision level
- Evaluate saga vs 2PC, outbox, and choreography/orchestration without implementation tutorials
- Define API and contract evolution strategy (versioning, compatibility, deprecation)
- Plan monolith-to-microservices migration (strangler, parallel run, cutover criteria)
- Align services with Team Topologies (stream-aligned, platform, enabling, complicated-subsystem)
- Assess build vs buy vs managed for cross-cutting capabilities
- Quantify NFR impact (latency budgets, reliability, operability, cost) per boundary option
- Produce ADRs, options matrices, and research memos with a clear recommendation
When NOT to Use
- Write or refactor production microservice code, handlers, or deployables →
senior-software-engineer
- Operate Kubernetes clusters, Terraform modules, or CI/CD pipelines only →
platform-engineer, cloud-engineer, infrastructure-engineer
- Design carrier/WAN routing, VPC topology, or physical network without application boundaries →
network-backbone-architect
- Implement brokers, outbox consumers, schema registry ops, or stream processing →
event-driven-architecture (when building), microservices-developer
- Enterprise portfolio strategy, operating model, and board-level where-to-play →
enterprise-strategist
- Load-test execution, caching implementation, and horizontal scale tuning only →
high-concurrency-scalability
- Cross-domain system architecture sign-off unrelated to service decomposition →
senior-system-architecture (hand off when scope is whole-estate ADR)
- Inventory, dependency maps, SLO gaps, API drift, or operational health on a live estate →
microservices-analyst
Related skills
| Need | Skill |
|---|
| Existing estate inventory, coupling, SLO/API drift, ops health | microservices-analyst |
| Cross-system ADRs, C4, estate-wide NFR sign-off | senior-system-architecture |
| Event contracts, brokers, outbox, sagas (implementation) | event-driven-architecture |
| Service code, gRPC/REST, twelve-factor deployables | senior-software-engineer, microservices-developer |
| IDP, golden paths, paved roads | platform-engineer |
| Cloud landing zone, IaC, cluster delivery | infrastructure-engineer, cloud-engineer |
| Application throughput, caching, scale testing | high-concurrency-scalability |
| Enterprise strategy, portfolio, org design | enterprise-strategist |
| Enterprise API hub, iPaaS, B2B integration programs | enterprise-integration-api-developer |
| Rollout, cutover, and rollback tactics | deployment-strategist |
Core Workflows
1. Frame the research question
Capture before comparing boundaries:
- Business capability and measurable outcome
- Constraints: teams, timeline, compliance, existing monolith/estate
- Reversibility (one-way vs two-way door)
- Non-goals and explicit out-of-scope peers
See references/microservice_researcher_scope.md.
2. Decompose the domain
Identify bounded contexts, ubiquitous language, and context maps (upstream/downstream, ACL, OHS).
Produce candidate services with ownership hypotheses—not a box diagram without data flow.
See references/domain_decomposition_and_boundaries.md.
3. Integration and consistency
For each boundary, document sync/async choice, data ownership, consistency model, and failure semantics.
Compare eventual consistency, saga compensation, and 2PC only when research warrants—not as default distributed transactions.
See references/integration_patterns_and_consistency.md.
4. Contracts and evolution
Define public API/event contracts, versioning rules, compatibility matrix, and deprecation timeline.
See references/api_contracts_and_evolution.md.
5. Migration and organization
Plan strangler slices, parity criteria, dual-write/read duration, and team alignment (Team Topologies).
See references/migration_strangler_and_org_alignment.md.
6. Deliverables and decision record
Package options matrix, NFR table, risks, recommendation, and follow-on owners (build vs research complete).
See references/research_deliverables_and_decision_records.md.
Principles
- Research before split—boundaries follow domain and team cognition, not org chart alone
- Prefer reversible experiments—strangler slices over big-bang when uncertainty is high
- One writer per aggregate—document who owns each consistency boundary
- Make trade-offs explicit—latency, ops burden, and team autonomy in the same table
- Cite patterns and literature—DDD, Team Topologies, enterprise integration patterns—without cargo-culting microservices
