Essential Microservice Design Patterns Every Architect Should Know

Design Goals & Principles

Microservice architectures aim to reduce overall cost, accelerate delivery, increase resilience, and improve visibility. Core principles include:

Scalability

Availability

Resilience

Flexibility

Autonomy & decentralized governance

Fault isolation

Auto‑configuration

DevOps‑driven continuous delivery

Decomposition Patterns

By Business Function

Apply the Single Responsibility Principle: each service implements a distinct business capability (e.g., Order Management, Customer Management).

By Bounded Context (DDD Sub‑Domain)

Classify sub‑domains as:

Core – the most valuable, competitive part of the business.

Supporting – important but not core; can be built internally or outsourced.

Generic – not business‑specific; often replaceable by off‑the‑shelf solutions.

Example order‑management sub‑domains: Product Catalog, Inventory Management, Order Management, Delivery Management.

By Transaction (Two‑Phase Commit)

Services participate in a distributed transaction coordinated by a transaction manager:

Prepare – all participants signal readiness.

Commit/Rollback – the coordinator issues the final decision.

2PC adds significant latency and is usually unsuitable for high‑throughput workloads.

Strangler Pattern

Gradually replace a monolith with microservices:

Transform – build a new parallel system.

Coexist – route traffic to both old and new systems while incrementally adding functionality.

Eliminate – retire the legacy monolith.

Bulkhead Pattern

Isolate components or pools of services so that a failure in one does not cascade to others, similar to compartmentalization in a ship.

Sidecar Pattern

Deploy auxiliary functionality in a separate container that shares the lifecycle of the main service (e.g., logging, monitoring, security).

Integration Patterns

API Gateway Pattern

The gateway provides a single entry point for all microservice calls, handling routing, protocol translation, response aggregation, authentication, rate limiting, and other cross‑cutting concerns.

Aggregator Pattern

Combine data from multiple services before returning a response. Two common implementations:

A composite microservice that calls required services, merges and transforms the data.

An API gateway that splits the request, gathers results, and assembles the final response.

Proxy Pattern

Expose three API modules through the gateway:

Mobile API for native clients.

Browser API for JavaScript front‑ends.

Public API for third‑party developers.

Gateway Routing Pattern

Map HTTP methods and paths to target service URLs, similar to reverse‑proxy routing in NGINX.

Chained Microservice Pattern

Services call each other sequentially (e.g., Sale → Product → Order). All calls are synchronous.

Branch Pattern

Mix aggregation and chaining: multiple parallel calls to different services are combined, allowing flexible branching based on business logic.

Client UI Composition Pattern

Front‑end single‑page applications (SPA) are built from multiple UI components, each backed by a distinct microservice (e.g., Angular or React components).

Database Patterns

Database per Service

Each service owns its own database, accessed only via the service’s API. Options include private tables, schema‑per‑service, or separate database servers.

Shared Database (Anti‑Pattern)

Temporarily sharing a database can ease migration from a monolith, but should be eliminated as services mature.

CQRS

Separate command (create, update, delete) and query responsibilities. The query side often uses materialized views and is frequently paired with event sourcing.

Event‑Driven Patterns

Event sourcing records state changes as immutable events in an append‑only store. Consumers build materialized views from these events, enabling reliable reconstruction of state and integration with external systems.

Saga Pattern

Coordinate distributed transactions without a single lock:

Choreography – services react autonomously to each other’s events.

Orchestration – a central saga orchestrator decides the order of actions.

Observability Patterns

Log Aggregation

Centralize logs from all service instances for search, analysis, and alerting (e.g., PCF Loggregator, AWS CloudWatch).

Metrics

Collect performance data per operation. Two models:

Push – services push metrics to systems like New Relic or AppDynamics.

Pull – monitoring tools scrape metrics (e.g., Prometheus).

Distributed Tracing

Assign a unique request ID that propagates through all services, enabling end‑to‑end traceability.

Health Checks

Expose a /health endpoint that verifies the service’s own status, connectivity to dependencies, and any custom logic.

Cross‑Cutting Concern Patterns

External Configuration

Store environment‑specific settings (URLs, certificates, etc.) outside the codebase so they can be reloaded without redeployment.

Service Discovery

Register services at startup and deregister on shutdown. Clients discover endpoints via a registry (e.g., Netflix Eureka) or server‑side mechanisms (e.g., AWS ALB).

Circuit Breaker

Wrap remote calls with a circuit breaker that opens after a failure threshold, immediately rejecting further calls until a timeout expires and a trial request succeeds.

Blue‑Green Deployment

Maintain two identical production environments (Blue and Green). At any time only one serves traffic, allowing seamless switchovers and rollbacks with zero downtime.

These patterns constitute a practical toolbox for designing, implementing, and operating robust microservice‑based systems.