Mastering Microservice Design Patterns: When, Why, and How to Apply Them

1 Microservice Architecture

Since the 1960s software engineers have tackled complexity with modularization, encapsulation and SOA, but these techniques fell short for modern web‑scale applications, leading to the rise of microservice architecture, which still follows divide‑and‑conquer but with independent deployable processes communicating via lightweight synchronous (REST, gRPC) or asynchronous (messaging) calls.

Key Features

Application split into independent subprocesses.

Vertical slicing by business domain rather than modular monolith.

Boundaries are external; services talk over the network.

Independent deployment.

Lightweight communication without a smart bus.

Advantages

Better development scale.

Faster delivery.

Supports iterative and incremental development.

Leverages cloud, containers, DevOps, serverless.

Horizontal and fine‑grained scaling.

Smaller cognitive load per team.

Disadvantages

More services, databases, containers, frameworks.

Complexity shifts to infrastructure.

Increased RPC and network traffic.

Security management becomes harder.

Overall system design is more difficult.

Introduces distributed‑system challenges.

When to Use

Large‑scale web applications.

Cross‑team enterprise development.

Long‑term ROI outweighs short‑term cost.

Teams with experienced architects or senior engineers.

2 Microservice Design Patterns

Database per Microservice

Each service owns its own data store, avoiding strong coupling at the database layer. Logical isolation can be achieved even on a shared physical database by using separate schemas or tables.

Pros

Data fully owned by the service.

Reduced coupling between teams.

Cons

Sharing data across services becomes harder.

ACID transactions across services are difficult.

Designing the split is challenging.

When to Use

Large enterprise applications.

Teams need full control for scaling.

When Not to Use

Small applications.

Single team owns all services.

Any SQL or NoSQL database can provide logical separation (separate tables, collections, etc.).

Event Sourcing

Instead of storing only the current state, every state‑changing event is persisted, allowing reconstruction of state by replaying events. This supports highly scalable, fault‑tolerant systems.

Pros

Atomic operations for scalable systems.

Automatic audit trail and time‑travel.

Loose coupling and event‑driven services.

Cons

Reading state requires replay or a separate query store (CQRS).

Overall system complexity increases.

Must handle idempotency and possible event loss.

Event schema evolution is challenging.

When to Use

High‑throughput transactional systems on SQL or NoSQL.

Event‑driven microservices.

E‑commerce, booking, reservation systems.

When Not to Use

Low‑scale transactional systems on SQL.

Simple services that can sync via API.

Technologies: EventStoreDB, Apache Kafka, Confluent Cloud, AWS Kinesis, Azure Event Hub, GCP Pub/Sub, MongoDB, Cassandra, DynamoDB, etc.

CQRS (Command‑Query Responsibility Segregation)

Separates write (command) and read (query) models. Simple CQRS uses separate ORM models; advanced CQRS pairs with Event Sourcing and distinct write/read stores.

Pros

Faster reads for event‑driven services.

High availability of data.

Independent scaling of read and write paths.

Cons

Read store is eventually consistent.

Added complexity can jeopardize projects.

When to Use

High‑scale microservices with event sourcing.

Complex domain models needing multiple data sources.

Read‑write load imbalance.

When Not to Use

When events are few and snapshots suffice.

When read/write loads are similar.

Write stores: EventStoreDB, Kafka, etc. Read stores: Elasticsearch, Solr, Cloud Spanner, Aurora, Neo4j, etc.

Saga

Provides distributed transaction management for microservices with independent databases by chaining local transactions that publish events; compensating transactions roll back on failure.

Pros

Consistent transactions for scalable, loosely‑coupled services.

Works with non‑2PC databases.

Cons

Requires handling instant failures and idempotency.

Debugging is hard; complexity grows with service count.

When to Use

Event‑sourced, loosely‑coupled microservices.

Systems using distributed NoSQL databases.

When Not to Use

Low‑scale transactional systems on relational DBs.

When services have circular dependencies.

Technologies: Axon, Eventuate, Narayana.

Backend‑for‑Frontend (BFF)

Creates a dedicated backend for each UI (web, mobile, TV) to tailor APIs, reduce client‑service chatter, and add an extra security layer.

Pros

Separate concerns per UI, enabling optimization.

Higher security.

Less frequent client‑to‑service calls.

Cons

Code duplication across BFFs.

Many BFFs increase maintenance.

Must avoid business logic in BFF.

When to Use

Multiple UIs with different API needs.

Security‑critical scenarios.

Micro‑frontend architectures.

When Not to Use

Multiple UIs share the same API.

Core services not in DMZ.

Supported by any backend framework (Node.js, Spring, Django, etc.).

API Gateway

Sits between clients and microservices, acting as a façade, routing, aggregating responses, and handling cross‑cutting concerns such as SSL termination, authentication, rate limiting, and logging.

Pros

Loose coupling between front‑end and services.

Reduces client‑service round trips.

Provides centralized security.

Manages cross‑cutting concerns centrally.

Cons

Potential single point of failure.

Additional latency.

Can become a bottleneck if not scaled.

Extra maintenance cost.

When to Use

Complex microservice landscapes.

Enterprise environments needing centralized security.

When Not to Use

Small projects where security isn’t primary.

Few microservices.

Technologies: Amazon API Gateway, Azure API Management, Apigee, Kong, WSO2.

Strangler

Migrates a monolith to microservices incrementally by routing requests through a façade (API gateway) and replacing functionality with new services until the old monolith can be retired.

Pros

Safe, incremental migration.

Parallel development of new features.

Controlled rollout pace.

Cons

Sharing data between legacy and new services is hard.

Facade adds latency.

End‑to‑end testing becomes more complex.

When to Use

Large backend monoliths needing incremental migration.

When Not to Use

Small monoliths where full rewrite is easier.

Cannot intercept client traffic to legacy system.

Implementation typically uses an API‑gateway framework.

Circuit Breaker

Protects a service from cascading failures by monitoring recent error rates and opening the circuit to fail fast, then half‑opening to test recovery.

Pros

Improves fault tolerance and resilience.

Prevents cascading failures.

Cons

Requires sophisticated error handling and monitoring.

Needs manual reset support.

When to Use

Synchronous, tightly‑coupled microservice calls.

Services depend on multiple downstream services.

When Not to Use

Event‑driven, loosely‑coupled architectures.

Service has no downstream dependencies.

Libraries: Hystrix, Resilience4j, Polly.

Externalized Configuration

Moves configuration out of the codebase into environment‑specific sources, reducing security risk and allowing changes without rebuilding.

Pros

Secrets are not stored in source code.

Configuration changes don’t require rebuilds.

Cons

Requires a framework that supports external config.

When to Use

Any production‑grade application.

When Not to Use

Proof‑of‑concept or prototype development.

Supported by virtually all modern enterprise frameworks.

Consumer‑Driven Contract Testing

Consumers define expectations (contracts) for provider APIs; providers run these contracts as part of their test suite to ensure compatibility.

Pros

Detects breaking changes early.

More robust integration in large microservice ecosystems.

Improves team autonomy.

Cons

Additional effort to create and maintain contracts.

Mismatches between contracts and real services can cause production failures.

When to Use

Large enterprise applications with many independently developed services.

When Not to Use

Small, single‑team projects.

Stable services with little change.

Tools: Pact, Postman, Spring Cloud Contract.

3 Summary

Microservice architecture enables scalable enterprise software but is not a universal silver bullet; teams should follow best practices and reuse proven design patterns. Core patterns include Database per Service, Event Sourcing, CQRS, Saga, BFF, API Gateway, Circuit Breaker, Strangler, Consumer‑Driven Contracts, and Externalized Configuration, each with specific trade‑offs and suitable scenarios.