Microservices Design Patterns — The Cheat Sheet

cheat sheet · design patterns

Microservices
Design Patterns

14 battle-tested patterns for designing and implementing microservices — what each solves, when to reach for it, and the trap to avoid. Patterns are tools, not goals.

API Gateway

Edge

[ Mobile ]┐
          ├─> [ API GATEWAY ] ─┬─> Users
[  Web   ]┘   authn·routing  ├─> Courses
              ratelimit·agg  └─> Payments

Single entry point that routes client requests and centralizes auth, load balancing, rate limiting, and aggregation.
Use when many clients hit many services. Trap: don't bury business logic in it; run several so it isn't a single point of failure.

API Composition

Query

query() ─> [ API Composer ]
            ├─ queryA() ─> Service A
            ├─ queryB() ─> Service B
            └─ queryC() ─> Service C
         <─ joined result

A composer invokes several services and stitches their results into one richer response.
Use when a client view spans multiple services. Trap: latency = the slowest call; in-memory joins get heavy — graduate to CQRS for big reads.

Service Registry

Discovery

svc starts ─> register(ip:port, health)
                    │
               [ REGISTRY ]
                    ▲
client ─ lookup("orders") ─> healthy IPs

Services self-register; clients discover live instances dynamically instead of hard-coding addresses.
Use when instances autoscale or move. Trap: the registry must be HA and prune dead instances via health checks. Consul · Eureka · etcd · k8s DNS

Circuit Breaker

Resilience

CLOSED ──fail × N──> OPEN ──cooldown──> HALF-OPEN
   ▲                                       │
   └──────────── probe ok ─────────────────┘
OPEN: fail fast + serve fallback

Stops calling a failing dependency, failing fast and serving a fallback so faults don't cascade.
Use when a remote call can hang or error. Trap: tune the thresholds and always define a fallback. Resilience4j · Polly · Istio

Bulkhead

Resilience

        ┌ pool A ─> Dep A
service ┤ pool B ─> Dep B   (isolated pools)
        └ pool C ─> Dep C
Dep B drowns ─> only pool B exhausts

Isolates resources (thread / connection pools) per dependency so one overload can't sink the whole service — like watertight ship compartments.
Use when a slow dep could starve everything. Trap: size each pool deliberately.

Retry

Resilience

call ─> ✗ error
  └ wait 1s  ─> retry ✗
  └ wait 2s  ─> retry ✓   (backoff + jitter)

Automatically re-attempts transient failures to improve the odds of success.
Use when errors are transient (blips, timeouts). Trap: only retry idempotent ops, cap attempts, add jitter, and pair with a circuit breaker to avoid retry storms.

Database per Service

Data

Orders    ─> [ orders_db ]
Customers ─> [ cust_db   ]
Reviews   ─> [ review_db ]
✗ no shared tables — reach data via APIs

Each service owns its private datastore, guaranteeing loose coupling and autonomy.
Use when you want services to evolve independently. Trap: cross-service joins & transactions disappear — solve with API Composition, Saga, and CQRS.

Saga

Consistency

Choreography  services react to events
  OrderCreated ─> Paid ─> Reserved ─> Shipped

Orchestration  a coordinator drives steps
  on failure ─> compensate (refund, unreserve)

Manages a transaction spanning services as a chain of local transactions, each with a compensating action.
Use when a business operation crosses service boundaries. Trap: there's no rollback — you must design compensations and accept eventual consistency.

CQRS

Data

      ┌ Command ─> write model ─> [ write_db ]
UI ───┤                            │ events
      └ Query   <─ read model  <─ [ read_db  ]

Splits the write path (commands) from the read path (queries), letting each be modeled and scaled on its own.
Use when read and write loads/shapes differ sharply. Trap: two models add complexity and usually eventual consistency between them.

Event-Driven Architecture

Comms

Producer ─ event ─> [ BROKER ] ─┬─> Consumer 1
                                 ├─> Consumer 2
                                 └─> Consumer 3

Services communicate by publishing and reacting to events, enabling loose coupling and independent scaling.
Use when workflows are async or fan out to many consumers. Trap: make consumers idempotent; ordering, dedup, and tracing get harder. Kafka · RabbitMQ · NATS

Sidecar

Cross-cutting

┌── Pod ───────────────────────┐
│ [ app ] ⇄ [ sidecar ]          │
│            logs · mTLS · cfg  │
└──────────────────────────────┘

Attaches a helper process/container alongside a service to handle cross-cutting concerns — monitoring, logging, config, proxying, auth.
Use when you want uniform infra across polyglot services (the basis of a service mesh). Trap: a little resource overhead per instance.

Config Externalization

Cross-cutting

Service 1 ┐
          ├ get config @ runtime ─> [ Config Store ]
Service 2 ┘
one image · many envs · live reload

Keeps configuration out of the codebase, fetched at runtime from a central store for easy management and updates.
Use when one artifact runs across environments or needs live changes. Trap: put secrets in a vault, and cache config to survive store outages. Spring Cloud Config · Consul · AppConfig

Strangler Fig

Migration

Client ─> [ PROXY ] ─┬─> legacy monolith (shrinking)
                    └─> new service     (growing)
route slices across until the old one is gone

Incrementally replaces a legacy system by redirecting functionality to new services behind a proxy until the old one is fully "strangled."
Use when migrating off a monolith without a risky big-bang rewrite. Trap: manage the routing layer and keep data in sync (CDC) during the transition.

Leader Election

Coordination

inst A ┐
inst B ┤─ elect ─> ★ leader  (runs the job once)
inst C ┘
leader dies ─> re-elect

Picks one instance among replicas to coordinate work or make decisions, so a singleton task runs exactly once.
Use when a scheduler/coordinator must not run in parallel. Trap: needs real consensus and split-brain handling. Raft · etcd lease · ZooKeeper

Satyam Kumar Das Founder & Solutions Architect · AppScale LLP

satyam@appscale.in
linkedin.com/in/satyamkumar