Microservice Researcher

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

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