Essential Microservice Architecture Patterns Every Backend Engineer Should Know

Preface

Microservices can have a positive impact on enterprises, so understanding how to handle microservice architecture (MSA) and some design patterns, as well as common goals and principles, is valuable.

Four goals worth considering in a microservice solution are:

Reduce cost: MSA lowers the overall cost of designing, implementing, and maintaining IT services.

Accelerate delivery: MSA speeds up the time from idea to deployment.

Increase resilience: MSA improves the resilience of the service network.

Enable visibility: MSA provides better visibility for services and the network.

Key design principles you need to know include:

Scalability

Availability

Resilience

Flexibility

Autonomy

Decentralized governance

Fault isolation

Auto‑configuration

Continuous delivery via DevOps

Applying the right design patterns can overcome common challenges. The diagram below shows the five categories of microservice design patterns.

Decomposition Patterns

Decompose by Business Capability

Microservices follow the single‑responsibility principle, turning services into loosely‑coupled units that map to business capabilities. Examples:

Order management handles orders.

Customer management handles customers.

Decompose by Subdomain

When decomposing by business capability reaches a “god class,” you can define services that correspond to subdomains from Domain‑Driven Design (DDD). Subdomains are:

Core – the most valuable part of the business.

Supporting – related to the business but not core.

Generic – not specific to the business and can be implemented with off‑the‑shelf software.

An order‑management subdomain might include:

Product catalog service

Inventory management service

Order management service

Delivery management service

Decompose by Transaction / Two‑Phase Commit (2PC)

You can split services by transaction boundaries, introducing multiple transactions coordinated by a distributed transaction coordinator. The two phases are:

Prepare phase – all participants signal they are ready to commit.

Commit or rollback phase – the coordinator tells participants to commit or roll back.

2PC is slow compared with a single microservice’s execution time and is usually unsuitable for high‑load scenarios.

Strangler Pattern

This pattern helps refactor large monolithic (brownfield) applications by creating a new parallel application that eventually replaces the old one. The steps are:

Transform – build a new parallel system using modern techniques.

Coexist – redirect traffic from the old system to the new one gradually.

Eliminate – remove the legacy monolith once the new system is fully functional.

Bulkhead Pattern

Isolate elements of an application into separate pools so that a failure in one does not bring down the whole system, similar to compartments in a ship.

Sidecar Pattern

Deploy a component of an application in a separate container to provide isolation and additional functionality, sharing the same lifecycle as the main application.

Integration Patterns

API Gateway Pattern

When an application is split into many microservices, an API gateway solves problems such as multiple calls from different channels, handling various protocols, and providing different response formats for consumers. Benefits include:

Single entry point for all microservice calls.

Acts as a proxy to route requests to the appropriate services.

Aggregates results and returns them to consumers.

Creates fine‑grained APIs for specific client types.

Can translate protocols and handle authentication/authorization.

Aggregator Pattern

After decomposing business functionality, you need to coordinate data returned by each service. Two implementation approaches are:

A composite microservice calls all required services, merges and transforms the data before returning it.

An API gateway splits the request to multiple services and aggregates the data before responding.

For business logic, a composite microservice is recommended; otherwise, the API gateway is a standard solution.

Proxy Pattern

The API gateway can expose three API modules:

Mobile API for FTGO mobile client.

Browser API for JavaScript client.

Public API for third‑party developers.

Gateway Routing Pattern

The gateway routes requests by looking up a mapping from HTTP method and path to a service URL, similar to reverse‑proxy functionality in NGINX.

Chained Microservice Pattern

A service may depend on multiple other services (e.g., Sale depends on Product and Order). The pattern helps provide merged request results across synchronous calls.

Branch Pattern

Combines aggregator and chained patterns, allowing concurrent requests to multiple services and branching logic based on business needs.

Client UI Composition Pattern

When developing services by decomposing business capabilities, the UI layer must fetch data from multiple microservices. Single‑page applications (SPA) frameworks like AngularJS or ReactJS enable this composition.

Database Pattern

When defining database schemas for microservices, consider:

Services must be loosely coupled.

Business transactions may span multiple services.

Some transactions need to query data from multiple services.

For scalability, databases may need to be replicated or shared.

Different services have different storage requirements.

Database‑per‑Service

Each microservice gets its own dedicated database, accessed only via the service’s API.

Shared Database Between Services

Sharing a database is an anti‑pattern for microservices but can be a pragmatic starting point when breaking a monolith (brownfield) into microservices.

Command Query Responsibility Segregation (CQRS)

Separates the system into a command side (create, update, delete) and a query side (read), often paired with event sourcing to keep materialized views up‑to‑date.

Command side handles write requests.

Query side uses materialized views for reads.

Event‑Driven

Instead of CRUD, an event‑driven model records state‑changing actions as events in an append‑only store, enabling materialized views and integration with external systems.

Saga Pattern

Ensures data consistency across services when a business transaction spans multiple databases. Two coordination approaches:

Choreography – services emit and listen to events without a central coordinator.

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

Observability Patterns

Log Aggregation

Centralized logging collects logs from all service instances, enabling search, analysis, and alerting.

Metrics

Metrics services gather statistics from individual services, either by push (e.g., NewRelic) or pull (e.g., Prometheus), to report and alert on performance.

Distributed Tracing

Assign a unique trace ID to each external request and propagate it across services to enable end‑to‑end request tracing.

Health Checks

Expose a health‑check endpoint (e.g., /health) that verifies the service’s own status and its dependencies.

Cross‑Cutting Concern Patterns

External Configuration

Store environment‑specific configuration (URLs, certificates, etc.) outside the code so services can reload settings without redeployment.

Service Discovery Pattern

Use a service registry (client‑side like Netflix Eureka or server‑side like AWS ALB) so services can discover each other despite dynamic IPs.

Circuit Breaker Pattern

Wrap remote calls with a circuit breaker that opens after a threshold of failures, preventing cascading failures and allowing fallback behavior.

Blue‑Green Deployment Pattern

Run two identical production environments (Blue and Green) and switch traffic between them to achieve zero‑downtime deployments and easy rollbacks.

Conclusion

Feel free to discuss, share opinions, and ask questions.