Essential Microservice Design Patterns Every Backend Engineer Should Master

Microservice Architecture Design Patterns

Database per Microservice

When replacing a monolithic system with microservices, the most critical decision is the database strategy. A monolith typically uses a single central database, but keeping the same database for microservices creates strong coupling and defeats the purpose of independent development.

A better approach is to give each microservice its own logical data store. Services may share a physical database but must use separate schemas, tables, or collections, ensuring proper domain‑driven design boundaries.

Advantages

Data is fully owned by the service.

Coupling between development teams is reduced.

Disadvantages

Data sharing between services becomes more challenging.

Maintaining ACID transactions across services is difficult.

Designing how to split the monolithic database is a complex task.

When to use

Large enterprise applications.

When teams need full control of services to scale development speed.

When not to use

Small‑scale applications.

When a single team develops all microservices.

Technology examples

All SQL and NoSQL databases support logical separation (separate tables, collections, schemas, or databases).

Event Sourcing

In microservice architectures that use dedicated databases, services need to exchange data. Asynchronous, event‑driven communication provides atomic operations without relying on two‑phase commit protocols, which do not scale for large distributed systems.

Event sourcing stores every state‑changing event instead of the current entity state. The full history of events can be replayed to reconstruct the current state, enabling immutable audit trails and decoupled services.

Advantages

Provides atomic operations for highly scalable systems.

Automatically records entity change history with time‑travel capability.

Enables loosely coupled, event‑driven microservices.

Disadvantages

Reading entities from the event store requires additional storage (CQRS).

Overall system complexity increases, often requiring domain‑driven design.

Handling duplicate or lost events adds operational overhead.

Changing event schemas is challenging.

When to use

Transactional systems built on relational or NoSQL databases that need high scalability.

Event‑driven or message‑driven applications such as e‑commerce, booking, and reservation systems.

When not to use

Low‑scalability transactional systems using SQL databases.

Simpler microservices that can synchronously exchange data via APIs.

Technology examples

Event stores: EventStoreDB, Apache Kafka, Confluent Cloud, AWS Kinesis, Azure Event Hub, GCP Pub/Sub, Azure Cosmos DB, MongoDB, Cassandra, Amazon DynamoDB. Frameworks: Lagom, Akka, Spring, akkatecture, Axon, Eventuate.

Command Query Responsibility Segregation (CQRS)

When using event sourcing, reading data becomes complex because the system must process all events to reconstruct state. CQRS separates the write side (commands) from the read side (queries), simplifying design and allowing independent scaling.

In its simple form, separate models are used for reads and writes. In the advanced form, distinct data stores are employed, often combined with event sourcing.

Advantages

Faster read performance in event‑driven microservices.

High data availability.

Read and write stores can be scaled independently.

Disadvantages

Read store is eventually consistent.

System complexity increases; misuse can jeopardize projects.

When to use

High‑scalability microservices using event sourcing.

Complex domain models requiring separate read queries.

Systems with significantly different read and write loads.

When not to use

Small applications where a single snapshot suffices.

Systems with balanced read/write workloads.

Technology examples

Write stores: EventStoreDB, Apache Kafka, Confluent Cloud, AWS Kinesis, Azure Event Hub, GCP Pub/Sub, Azure Cosmos DB, MongoDB, Cassandra, Amazon DynamoDB. Read stores: Elasticsearch, Solr, Cloud Spanner, Amazon Aurora, Azure Cosmos DB, Neo4j. Frameworks: Lagom, Akka, Spring, akkatecture, Axon, Eventuate.

Backend for Frontend (BFF)

When a product has multiple UI clients (web, mobile, desktop, smart devices), each with different performance, bandwidth, and security requirements, a dedicated backend per UI can tailor APIs, reduce chatty communication, and provide an extra security layer.

Advantages

Separates concerns, allowing UI‑specific optimizations.

Improves security.

Reduces frequent communication between UI and downstream services.

Disadvantages

Potential code duplication across BFFs.

Management overhead for many BFFs (TV, web, mobile, desktop).

Requires careful design to keep business logic out of the BFF.

When to use

Multiple UIs with distinct API needs.

Security requirements demand an extra layer between UI and services.

Micro‑frontend architectures.

When not to use

Multiple UIs that share the same API.

Backend services are not deployed in a DMZ.

Technology examples

Any backend framework (Node.js, Spring, Django, Laravel, Flask, Play, …) can implement a BFF.

API Gateway

In microservice architectures, clients often need to call many fine‑grained services. An API gateway acts as a façade, routing requests, aggregating responses, and handling cross‑cutting concerns such as SSL termination, authentication, rate limiting, and logging.

Advantages

Provides loose coupling between front‑end and back‑end services.

Reduces the number of client‑to‑service calls.

Enables high security via SSL termination, authentication, and authorization.

Centralizes cross‑cutting concerns (logging, monitoring, throttling, load balancing).

Disadvantages

Can become a single point of failure.

Additional network hop adds latency.

May become a bottleneck if not scaled.

Increases maintenance and development costs.

When to use

Complex microservice landscapes where a gateway is almost mandatory.

Large enterprises needing centralized security and cross‑cutting management.

When not to use

Small projects or private deployments where security and central management are not priorities.

When the number of microservices is very low.

Technology examples

Amazon API Gateway, Azure API Management, Apigee, Kong, WSO2 API Manager.

Strangler Fig

To migrate a legacy monolith to microservices, the Strangler Fig pattern incrementally replaces functionality with new services while routing traffic through a façade (often an API gateway). Over time the monolith is “strangled” and retired.

Advantages

Safe migration from monolith to microservices.

Allows parallel development of new features and migration of existing ones.

Provides better control over migration pace.

Disadvantages

Sharing data stores between legacy and new services is challenging.

Adding a façade introduces latency.

End‑to‑end testing becomes more difficult.

When to use

Incrementally migrate large backend monoliths to microservices.

When not to use

Small monoliths where a full replacement is simpler.

When you cannot intercept client requests to the legacy system.

Technology examples

API gateway backend frameworks.

Circuit Breaker

Synchronous calls between microservices can fail due to transient faults. A circuit breaker monitors failure rates and, when a threshold is exceeded, short‑circuits calls to prevent cascading failures.

States

Closed : Requests flow normally; failures are counted.

Open : Requests fail fast; after a timeout the breaker moves to half‑open.

Half‑Open : A limited number of requests are allowed; success closes the breaker, failure re‑opens it.

Advantages

Improves fault tolerance and resilience.

Prevents cascading failures across services.

Disadvantages

Requires complex exception handling and monitoring.

Needs manual reset mechanisms.

When to use

Synchronously coupled microservices where a service depends on many others.

When not to use

Loose‑coupled, event‑driven architectures.

Services that do not call other services.

Technology examples

API gateways, service meshes, and libraries such as Hystrix, Resilience4j, Polly.

Externalized Configuration

Embedding configuration (database URLs, credentials, etc.) in code is a security risk and forces rebuilds for changes. Externalizing configuration separates build from runtime, allowing parameters to be supplied via environment variables or external files.

Advantages

Production configuration is not stored in source code, reducing security exposure.

Changing parameters does not require rebuilding the application.

Disadvantages

Requires a framework that supports externalized configuration.

When to use

Any important production application.

When not to use

Proof‑of‑concept or prototype development.

Technology examples

Virtually all modern enterprise frameworks provide support.

Consumer‑Driven Contract Testing

In large microservice ecosystems, integration testing is hard. Consumer‑driven contract tests let the consumer define expected requests and responses. Providers then run these contracts as part of their own test suites, ensuring compatibility.

Advantages

Detects breaking API changes quickly.

Reduces surprises and increases robustness in large systems.

Improves team autonomy.

Disadvantages

Additional effort to develop and maintain contracts.

If contracts diverge from real behavior, production failures may occur.

When to use

Large enterprise applications with many independently developed services.

When not to use

Small applications where all services are owned by a single team.

Stable services that rarely change.

Technology examples

Pact, Postman, Spring Cloud Contract.

Summary

Microservice architecture can scale development and deliver long‑term benefits, but it is not a universal silver bullet. Teams should follow best practices and reuse proven design patterns. Core patterns include Database per Service, supported by Event Sourcing, CQRS, and Saga. For multiple client types, Backend for Frontend and API Gateway are valuable. Circuit Breaker helps with error handling. Strangler Fig eases migration from monoliths. Consumer‑Driven Contract Testing underpins integration testing, while Externalized Configuration is essential for modern applications.