MicroService Design Patterns

Here is an extensive list of microservices design patterns, grouped by category, with a minimal explanation for each.

1. Decomposition Patterns

  • Decompose by Business Capability: Structure services around distinct business functions (e.g., “Order Management,” “Inventory”).
  • Decompose by Subdomain: Use Domain-Driven Design (DDD) subdomains to define service boundaries, aligning with the problem space.
  • Strangler Fig Pattern: Incrementally replace a legacy monolith by routing requests to new microservices until the old system is “strangled.”

2. Integration & Communication Patterns

  • API Gateway: A single entry point for all clients that routes requests to the appropriate downstream services.
  • Backend for Frontend (BFF): A specialized API Gateway for a specific client type (e.g., a mobile app), providing a tailored API.
  • Gateway Routing: The core function of an API Gateway, routing incoming requests to the correct service instance.
  • Gateway Aggregation: The gateway calls multiple microservices and combines their results into a single, aggregated response for the client.
  • Gateway Offloading: The gateway handles cross-cutting concerns like SSL termination, authentication, or caching for all services.
  • Service Discovery: Enables services to find the network locations (IP/port) of other services dynamically.
  • Asynchronous Messaging: Services communicate via messages over a broker, decoupling sender from receiver and improving resilience.
  • Remote Procedure Invocation (RPC): A service directly calls a specific function or procedure in another service (e.g., using gRPC).

3. Data Management Patterns

  • Database per Service: Each microservice exclusively owns and controls its own database, ensuring loose coupling.
  • Saga: Manages data consistency across services in a distributed transaction using a sequence of local transactions and compensating actions.
  • API Composition: A service fetches and combines data from multiple other services by calling their APIs.
  • Command Query Responsibility Segregation (CQRS): Separates data models and operations for reading (Queries) from those for writing (Commands).
  • Event Sourcing: Persists an application’s state as an immutable sequence of events rather than storing the current state directly.
  • Shared Database: Multiple services share a single database; generally considered an anti-pattern as it creates tight coupling.

4. Observability Patterns

  • Log Aggregation: Consolidates logs from all services into a centralized location for searching and analysis.
  • Distributed Tracing: Tracks a single request’s journey across multiple services to diagnose latency and errors.
  • Health Check API: An endpoint on each service that external tools can query to check its operational status (e.g., up, down, degraded).
  • Application Metrics: Services expose performance metrics (e.g., latency, error rate, request count) for monitoring and alerting.

5. Resilience & Fault Tolerance Patterns

  • Circuit Breaker: Stops requests from being sent to a failing service for a period of time, preventing cascading failures.
  • Bulkhead: Isolates service resources (like connection pools or threads) so that a failure in one area doesn’t exhaust all resources.
  • Retry: Automatically re-issues a request to a service if the initial attempt fails.
  • Timeout: Sets a maximum wait time for a response from another service to prevent resources from being blocked indefinitely.
  • Rate Limiter / Throttling: Restricts how many requests a client or service can make in a given time period to prevent overload.

6. Cross-Cutting Concern Patterns

  • Externalized Configuration: Stores configuration data outside of the application code, allowing for easier management and dynamic updates.
  • Access Token: Secures APIs by requiring clients to present a token (e.g., JWT) which is validated by the service or gateway.
  • Service Template: A standardized, pre-configured boilerplate project for building a new microservice, ensuring consistency.

7. Deployment Patterns

  • Blue/Green Deployment: Deploys a new version (Green) alongside the old one (Blue), then switches traffic instantly once the new version is verified.
  • Canary Release: Gradually rolls out a new version to a small subset of users before releasing it to everyone.
  • Rolling Deployment: Slowly replaces instances of the old version of a service with instances of the new version one by one.
  • Service per Container: Deploys each service instance in its own isolated container (e.g., Docker).