# Microservice Researcher

> 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

- Skill: `daemon-blockint-tech/microservice-researcher` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add daemon-blockint-tech/microservice-researcher`
- Raw SKILL.md: https://api.skillmd.com/api/skills/daemon-blockint-tech/microservice-researcher/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: daemon-blockint-tech (https://skillmd.com/u/daemon-blockint-tech)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/daemon-blockint-tech/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

| 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