Microservices Developer

When to Use

• Decompose a monolith or greenfield system into bounded contexts and service boundaries
• Design REST, gRPC, or event contracts between services with clear ownership
• Choose sync vs async communication and document failure semantics
• Implement resilience—timeouts, retries with jitter, circuit breakers, bulkheads, load shedding
• Enforce database-per-service (or schema-per-service) and avoid shared mutable stores
• Apply saga, outbox, or idempotent consumers for cross-service consistency
• Containerize services with twelve-factor config, health checks, and graceful shutdown
• Add observability—correlation/trace IDs, RED metrics, structured logs, trace propagation
• Plan API versioning, deprecation, and backward compatibility at gateway or mesh edge
• Introduce contract tests or consumer-driven contract checks between teams

When NOT to Use

• Operate Kubernetes clusters, Helm platform add-ons, or cluster SRE only → platform-engineer, cluster-deployment-engineer
• Define org-wide SLO programs, error budgets, and PRR gates → site-reliability-engineer
• Design enterprise iPaaS, canonical enterprise models, or B2B integration hubs → enterprise-integration-api-developer
• Build monolith features, general RFCs, or stack-agnostic code review without service split → senior-software-engineer
• Implement CI/CD pipelines, GitOps, or release automation only → devops
• Provision VPC, managed cloud services, or landing zones → cloud-engineer, infrastructure-engineer
• Gate production builds and artifact promotion policy → build-validator
• Profile p99 latency and run load/soak tests as the main task → performance-engineer
• Classified air-gapped pipelines, ATO evidence, cleared promotion → classified-software-devsecops-engineer

Related skills

Core Workflows

1. Scope and boundaries

Map domains, define service APIs, and document non-goals.

See references/microservicesdeveloperscope.md and references/serviceboundariesand_design.md.

2. Communication and contracts

Pick sync/async patterns; define schemas, errors, and versioning.

See references/communicationsyncasync.md.

3. Resilience and reliability

Apply timeouts, retries, breakers, and failure isolation per dependency.

See references/resilienceandreliability.md.

4. Data, events, and consistency

Own data per service; use outbox/saga where cross-service invariants matter.

See references/dataconsistencyand_events.md.

5. Operate, test, and ship

Observability, contract tests, twelve-factor deploy, gateway compatibility.

See references/observabilitytestingdeployment.md.

Outputs

• Service map — contexts, APIs, data ownership, sync/async edges
• Contract draft — OpenAPI/proto/event schema with error model and versioning note
• Resilience table — per-dependency timeout, retry, breaker, fallback
• Consistency note — saga/outbox/idempotency choice with failure compensation
• Runbook snippet — health checks, dashboards, rollback triggers

Principles

• Prefer fewer, cohesive services over fine-grained chatter; split on change cadence and team boundaries
• Fail fast with explicit timeouts; never unbounded blocking across the network
• Design for partial failure—degrade features, do not cascade outages
• Make contracts testable before production coupling multiplies