Mastering Microservice Patterns: From Decomposition to Resilience

This article introduces mainstream microservice patterns and explains why microservices can positively impact enterprises. It outlines four primary goals of microservice architecture: reducing cost, accelerating releases, enhancing resilience, and improving visibility.

Design Principles

Scalability

Availability

Resilience

Flexibility

Autonomy / Self‑governance

Decentralized governance

Fault isolation

Auto‑configuration

Continuous delivery via DevOps

Decomposition Patterns

By Business Function

Applying the single‑responsibility principle, services are split according to business functions, e.g., an Order Management service handles orders while a Customer Management service handles customers.

By Domain Sub‑domain (DDD)

Using Domain‑Driven Design, services align with sub‑domains such as Core (business‑critical), Supporting (non‑core but necessary), and Generic (can be off‑the‑shelf). Example sub‑domains for order management include Product Catalog, Inventory Management, Order Management, and Delivery Management.

Two‑Phase Commit (2PC) Decomposition

Transactions are divided into a preparation phase where participants ready themselves, and a commit/rollback phase where the coordinator finalizes the transaction. 2PC can be slow and unsuitable for high‑load scenarios.

Strangler Pattern

For migrating monoliths, the pattern follows three steps: Transform – build a new parallel service; Coexist – route traffic to both old and new services; Eliminate – retire the legacy component.

Bulkhead Pattern

Isolates pools of service instances to prevent failures in one pool from affecting others, similar to compartments in a ship.

Sidecar Pattern

Deploys auxiliary components alongside a service to provide additional functionality while sharing the same lifecycle.

Integration Patterns

API Gateway Pattern

Acts as a single entry point for all microservice calls, handling routing, protocol translation, response aggregation, and authentication/authorization.

Aggregator Pattern

Combines data from multiple services before returning a response, either via a dedicated aggregator service or through the API gateway.

Proxy Pattern

Defines separate API modules for mobile, browser, and public consumers, each exposing the appropriate service interfaces.

Gateway Routing Pattern

Routes requests to target services based on HTTP method and path, similar to reverse‑proxy solutions like NGINX.

Chained Microservice Pattern

Describes multi‑level service dependencies where a request may traverse several services synchronously.

Branch Pattern

Allows parallel calls to multiple services, merging responses to satisfy complex business needs.

Client UI Composition Pattern

Builds user interfaces from multiple service‑backed components (e.g., SPA frameworks like Angular or React), each fetching data from its own backend service.

Database Patterns

When defining databases for microservices, consider that services should be loosely coupled, support independent deployment, and handle cross‑service transactions carefully.

Per‑Service Database

Each service owns its own database, accessed only via its API, using approaches such as private tables, schema‑per‑service, or dedicated database servers.

Shared Database (Anti‑Pattern)

While generally discouraged, shared databases may be a pragmatic step when refactoring a monolith into microservices, especially for brownfield migrations.

CQRS Pattern

Separates command handling (create, update, delete) from query handling (using materialized views), often combined with event‑sourcing to keep views up‑to‑date.

Observability Patterns

Log Aggregation

Centralizes logs from all service instances, enabling search, analysis, and alerting (e.g., PCF Log Aggregator, AWS CloudWatch).

Metrics

Collects performance data via push (NewRelic, AppDynamics) or pull (Prometheus) models.

Distributed Tracing

Uses a unique trace ID propagated across services to enable end‑to‑end request tracing.

Health‑Check Pattern

Exposes a /health endpoint that verifies host status, connectivity to dependencies, and custom health logic.

Cross‑Cutting Concern Patterns

External Configuration

Externalizes configuration such as endpoint URLs and certificates, allowing updates without rebuilding or redeploying services.

Service Discovery

Registers services in a discovery registry (client‑side like Netflix Eureka or server‑side like AWS ALB) to avoid hard‑coded URLs.

Circuit Breaker

Prevents cascading failures by short‑circuiting calls to unhealthy downstream services after a failure threshold is reached.

Blue‑Green Deployment

Runs two identical production environments (Blue and Green) to enable zero‑downtime releases and easy rollbacks.