microservice-researcher
|
Works with
--- name: microservice-researcher description: | license: MIT --- # 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
More Architecture skills
architecture-decision-records
wshobson/agents
Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.
microservices-patterns
wshobson/agents
Design microservices architectures with service boundaries, event-driven communication, and resilience patterns. Use when building distributed systems, decomposing monoliths, or implementing microservices.
clickhouse-architecture-advisor
clickhouse/agent-skills
MUST USE when designing ClickHouse architectures, selecting between ingestion or modeling patterns, or translating best practices into workload-specific system designs. Complements clickhouse-best-practices with decision frameworks and explicit provenance labels.

