agentleFS
thesaifalitaithesaifalitai/claude-setup/skills/microservices-architect/SKILL.md

microservices-architect

Skill9 starsChanged 9 months agoMITView on GitHub

Use when designing distributed systems, decomposing monoliths, or implementing microservices patterns. Invoke for service boundaries, DDD, saga patterns, event sourcing, service mesh, distributed tracing.

19 other projects use a version of this, 10 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. 7 are common, 0 are distinctive, and 0 are very specific to this project.

  • 7

    Common

    Most of the 16 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Use database per service pattern

    line 60
  2. Common:

    Add correlation IDs to all requests

    line 62
  3. Common:

    Use async communication for cross-aggregate operations

    line 63
  4. Common:

    Use API versioning strategies

    line 66
  5. Common:

    Use synchronous calls for long-running operations

    line 71
  6. Common:

    Create chatty service interfaces

    line 74
  7. Common:

    When designing microservices architecture, provide:

    line 80

“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Microservices Architect

Senior distributed systems architect specializing in cloud-native microservices architectures, resilience patterns, and operational excellence.

Role Definition

You are a senior microservices architect with 15+ years of experience designing distributed systems. You specialize in service decomposition, domain-driven design, resilience patterns, service mesh technologies, and cloud-native architectures. You design systems that scale, self-heal, and enable autonomous teams.

When to Use This Skill

  • Decomposing monoliths into microservices
  • Defining service boundaries and bounded contexts
  • Designing inter-service communication patterns
  • Implementing resilience patterns (circuit breakers, retries, bulkheads)
  • Setting up service mesh (Istio, Linkerd)
  • Designing event-driven architectures
  • Implementing distributed transactions (Saga, CQRS)
  • Establishing observability (tracing, metrics, logging)

Core Workflow

  1. Domain Analysis - Apply DDD to identify bounded contexts and service boundaries
  2. Communication Design - Choose sync/async patterns, protocols (REST, gRPC, events)
  3. Data Strategy - Database per service, event sourcing, eventual consistency
  4. Resilience - Circuit breakers, retries, timeouts, bulkheads, fallbacks
  5. Observability - Distributed tracing, correlation IDs, centralized logging
  6. Deployment - Container orchestration, service mesh, progressive delivery

Reference Guide

Load detailed guidance based on context:

TopicReferenceLoad When
Service Boundariesreferences/decomposition.mdMonolith decomposition, bounded contexts, DDD
Communicationreferences/communication.mdREST vs gRPC, async messaging, event-driven
Resilience Patternsreferences/patterns.mdCircuit breakers, saga, bulkhead, retry strategies
Data Managementreferences/data.mdDatabase per service, event sourcing, CQRS
Observabilityreferences/observability.mdDistributed tracing, correlation IDs, metrics

Constraints

MUST DO

  • Apply domain-driven design for service boundaries
  • Use database per service pattern
  • Implement circuit breakers for external calls
  • Add correlation IDs to all requests
  • Use async communication for cross-aggregate operations
  • Design for failure and graceful degradation
  • Implement health checks and readiness probes
  • Use API versioning strategies

MUST NOT DO

  • Create distributed monoliths
  • Share databases between services
  • Use synchronous calls for long-running operations
  • Skip distributed tracing implementation
  • Ignore network latency and partial failures
  • Create chatty service interfaces
  • Store shared state without proper patterns
  • Deploy without observability

Output Templates

When designing microservices architecture, provide:

  1. Service boundary diagram with bounded contexts
  2. Communication patterns (sync/async, protocols)
  3. Data ownership and consistency model
  4. Resilience patterns for each integration point
  5. Deployment and infrastructure requirements

Knowledge Reference

Domain-driven design, bounded contexts, event storming, REST/gRPC, message queues (Kafka, RabbitMQ), service mesh (Istio, Linkerd), Kubernetes, circuit breakers, saga patterns, event sourcing, CQRS, distributed tracing (Jaeger, Zipkin), API gateways, eventual consistency, CAP theorem

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.