microservices

Original：🇺🇸 English
Translated

Microservices distributed architecture pattern. Use for scalable systems.

5installs
Sourceg1joshi/agent-skills
Added on

NPX Install

npx skill4agent add g1joshi/agent-skills microservices

Tags

Translated version includes tags in frontmatter
microservices-architecturedistributed-systemsapi-gatewaysaga-patterncicd-practices

SKILL.md Content

View Translation Comparison →

Microservices

Microservices architecture structures an application as a collection of loosely coupled, independently deployable services. Ideally, each service corresponds to a Bounded Context (DDD).

When to Use

  • Large teams (50+ devs) where coordination on a monolith slows down deployment.
  • Modules have conflicting resource requirements (e.g., one needs huge RAM, another needs GPU).
  • Need to scale specific parts of the system independently.
  • 2025 Reality check: Don't start with Microservices. Start with a Modular Monolith.

Quick Start

yaml
# docker-compose.yml (Simulated Microservices)
services:
  order-service:
    build: ./services/order
    ports: ["3001:3000"]
    environment:
      - DB_HOST=order-db

  inventory-service:
    build: ./services/inventory
    ports: ["3002:3000"]

  api-gateway:
    image: nginx
    ports: ["80:80"]
    depends_on:
      - order-service
      - inventory-service

Core Concepts

Independence

Each service owns its own data. Service A cannot query Service B's database directly; it must ask Service B via API.

Inter-Service Communication

  • Synchronous: HTTP/REST or gRPC (Request/Response). Tightly coupled in time.
  • Asynchronous: Message Queues (RabbitMQ, Kafka, SQS). Decoupled in time.

Database per Service

Ensures loose coupling. If a service needs data from another, use data replication (Events) or API composition.

Common Patterns

API Gateway

A single entry point for all clients. Handles routing, auth, rate limiting, and aggregation.

Circuit Breaker

Detects failures and prevents the application from trying to perform the action that is doomed to fail (e.g., external service down), protecting the system.

Saga Pattern

Managing distributed transactions. Since you can't have ACID across services, use Sagas (sequence of local transactions) with compensating actions for rollbacks.

Best Practices

Do:
  • Automate CI/CD and Infrastructure as Code (Terraform/K8s). You can't manage 50 services manually.
  • Implement Distributed Tracing (OpenTelemetry) immediately.
  • Define clear Service Boundaries (use DDD).
Don't:
  • Don't share code libraries for domain logic (leads to "Distributed Monolith"). Share utils only.
  • Don't use synchronous calls for everything (cascading failures).
  • Don't underestimate the Operational Complexity (Logging, Monitoring, Auth).

Troubleshooting

ErrorCauseSolution
Cascading Failure
One service down takes down others.Use Circuit Breakers and Timeouts.
Data inconsistency
Async updates failed.Implement Sagas and Idempotent consumers.
Latency
Too many hops (service -> service -> service).Use Caching, Aggregation at Gateway, or Event-Driven data replication.

References