home / skills / nickcrew / claude-cortex / microservices-patterns

microservices-patterns skill

safe

This skill guides designing and operating resilient microservices, helping you decompose monoliths, define boundaries, and implement robust communication.

npx playbooks add skill nickcrew/claude-cortex --skill microservices-patterns

Review the files below or copy the command above to add this skill to your agents.

Files (8)

SKILL.md

3.7 KB

---
name: microservices-patterns
description: Comprehensive microservices architecture patterns covering service decomposition, communication, data management, and resilience strategies. Use when designing distributed systems, breaking down monoliths, or implementing service-to-service communication.
---

# Microservices Architecture Patterns

Expert guidance for designing, implementing, and operating microservices architectures.

## When to Use This Skill

- Breaking down monolithic applications into services
- Designing distributed systems from scratch
- Implementing service communication patterns (sync/async)
- Managing data consistency across services
- Building resilient distributed systems
- Defining service boundaries and API contracts

## Core Principles

1. **Single Responsibility** - Each service has one reason to change
2. **Independent Deployability** - No coordination required for deployments
3. **Decentralized Data** - Each service owns its data exclusively
4. **Design for Failure** - Embrace failures, build resilience
5. **Automate Everything** - Deployment, scaling, and recovery

## Quick Reference

Load detailed patterns on-demand:

| Task | Load Reference |
| --- | --- |
| Define service boundaries and decompose monoliths | `skills/microservices-patterns/references/service-decomposition.md` |
| Implement service communication (sync/async) | `skills/microservices-patterns/references/communication-patterns.md` |
| Manage data consistency and transactions | `skills/microservices-patterns/references/data-management.md` |
| Build resilient systems (circuit breakers, retries) | `skills/microservices-patterns/references/resilience-patterns.md` |
| Add observability (tracing, logging, metrics) | `skills/microservices-patterns/references/observability.md` |
| Plan deployments and migrations | `skills/microservices-patterns/references/deployment-migration.md` |

## Workflow

### 1. Understand Requirements
- Map business capabilities and domains
- Assess scalability/resilience needs
- Identify team boundaries

### 2. Define Service Boundaries
Load `references/service-decomposition.md` for:
- Business capability decomposition
- DDD bounded contexts
- Service boundary validation

### 3. Design Communication
Load `references/communication-patterns.md` for:
- Synchronous: API Gateway, REST, gRPC
- Asynchronous: Message Queue, Pub/Sub, Event Sourcing

### 4. Manage Data
Load `references/data-management.md` for:
- Database per service pattern
- Saga distributed transactions
- CQRS read/write optimization

### 5. Build Resilience
Load `references/resilience-patterns.md` for:
- Circuit breakers
- Retry with exponential backoff
- Bulkhead isolation
- Rate limiting and timeouts

### 6. Add Observability
Load `references/observability.md` for:
- Distributed tracing
- Centralized logging
- Metrics and monitoring

### 7. Plan Deployment
Load `references/deployment-migration.md` for:
- Blue-Green, Canary, Rolling deployments
- Strangler Fig migration pattern

## Common Mistakes

1. **Distributed Monolith** - Tightly coupled, must deploy together
2. **Shared Database** - Multiple services accessing same database
3. **Chatty APIs** - Excessive synchronous service calls
4. **Missing Circuit Breakers** - No cascading failure protection
5. **No Observability** - Deploying without tracing/logging/metrics
6. **Ignoring Network Failures** - Assuming reliable network
7. **No API Versioning** - Breaking changes without versioning

**Fixes**: Load relevant reference files for detailed solutions.

## Resources

- **Books**: "Building Microservices" (Newman), "Microservices Patterns" (Richardson)
- **Sites**: microservices.io, martinfowler.com/microservices
- **Tools**: Kubernetes, Istio, Kafka, Kong, Jaeger, Prometheus

Overview

This skill provides a concise, practical catalogue of microservices architecture patterns for designing, implementing, and operating distributed systems. It guides service decomposition, communication models, data management, resilience strategies, observability, and migration approaches. Use it to make concrete architectural decisions when breaking apart a monolith or building a new distributed system.

How this skill works

The skill organizes patterns by concern: service decomposition, synchronous and asynchronous communication, data ownership and consistency, resilience techniques, observability, and deployment strategies. For each concern it explains the problem, applicable patterns, trade-offs, and actionable implementation steps. It also highlights common anti-patterns and corrective actions to avoid distributed-monolith failures and operational surprises.

When to use it

Decomposing a monolith into independently deployable services
Designing service-to-service communication (REST, gRPC, events, queues)
Choosing data ownership models and managing distributed consistency
Implementing resilience (circuit breakers, retries, bulkheads)
Planning deployments and migration strategies (canary, blue-green, strangler fig)
Adding observability: tracing, centralized logs, and metrics

Best practices

Define service boundaries around business capabilities and bounded contexts
Give each service exclusive ownership of its data; avoid a shared database
Prefer asynchronous communication where latency and coupling are concerns
Design for failure: add timeouts, retries with backoff, circuit breakers, and bulkheads
Automate CI/CD, testing, and deployment pipelines for independent deployability
Instrument services for tracing, logging, and metrics from day one

Example use cases

Splitting a legacy monolith by business domain into multiple teams owning services
Implementing an event-driven order pipeline using pub/sub to decouple services
Using saga patterns to coordinate multi-service transactions without distributed locks
Applying circuit breakers and bulkheads on third-party integrations to prevent cascading failures
Migrating with a Strangler Fig pattern to incrementally replace legacy endpoints

FAQ

How do I choose between synchronous and asynchronous communication?

Use synchronous calls for low-latency, request/response interactions and when strong consistency is required. Use asynchronous messaging to decouple services, improve resilience, and scale independently when eventual consistency is acceptable.

What is the best way to manage data consistency across services?

Prefer database-per-service to enforce ownership, and use patterns like sagas or compensating transactions for cross-service workflows. Consider CQRS to separate read and write models where it reduces contention and improves performance.

How do I avoid creating a distributed monolith?

Keep service boundaries clear, minimize synchronous chatty calls between services, enforce independent deployability with CI/CD, and ensure teams can own lifecycle and data for their services.