Skip to main contentSkip to user menuSkip to navigation
System Designer
Back to Reference

Microservices Patterns

Not Started
Loading...

Microservices Patterns

Comprehensive guide to microservices patterns and anti-patterns

11
Patterns Available
Decomposition
medium

Decompose by Business Capability

Organize services around business capabilities rather than technical layers

Use Case:

When you need to align services with business domains and reduce coupling

Pros:

  • +Services aligned with business functions
  • +Teams can work independently
  • +Clear service boundaries

Cons:

  • -Requires deep business domain knowledge
  • -May result in data duplication
  • -Complex cross-service transactions

Examples:

Order Management ServiceCustomer ServiceInventory Service
Decomposition
high

Decompose by Subdomain

Use Domain-Driven Design subdomains to define service boundaries

Use Case:

When applying DDD principles to microservices architecture

Pros:

  • +Clear domain boundaries
  • +Reduced coupling between services
  • +Better team autonomy

Cons:

  • -Requires DDD expertise
  • -Complex domain modeling
  • -Potential service proliferation

Examples:

Core Domain: Order ProcessingSupporting Domain: User ManagementGeneric Domain: Notification Service
Data Management
high

Database per Service

Each microservice has its own private database

Use Case:

When you need data isolation and service autonomy

Pros:

  • +Service independence
  • +Technology diversity
  • +Better fault isolation

Cons:

  • -Data consistency challenges
  • -Complex queries across services
  • -Increased operational overhead

Examples:

User Service → PostgreSQLOrder Service → MongoDBAnalytics Service → ClickHouse
Data Management
low

Shared Database

Multiple services sharing the same database

Use Case:

Never recommended - included as anti-pattern example

Pros:

  • +Simple ACID transactions
  • +Easy data consistency
  • +Familiar development model

Cons:

  • -Tight coupling between services
  • -Difficult to scale independently
  • -Technology lock-in

Examples:

Multiple services accessing same tablesShared stored proceduresCross-service foreign keys
Data Management
high

Saga Pattern

Manage distributed transactions using a sequence of local transactions

Use Case:

When you need to maintain data consistency across multiple services

Pros:

  • +Maintains data consistency
  • +Better fault tolerance
  • +No distributed locks

Cons:

  • -Complex error handling
  • -Eventual consistency
  • -Difficult debugging

Examples:

Order → Payment → Inventory → ShippingChoreography-based sagaOrchestration-based saga
Communication
medium

API Gateway

Single entry point for all client requests to microservices

Use Case:

When you need to manage cross-cutting concerns and client complexity

Pros:

  • +Single entry point
  • +Cross-cutting concerns handling
  • +Request routing and composition

Cons:

  • -Single point of failure
  • -Performance bottleneck
  • -Additional complexity

Examples:

AWS API GatewayKongZuul
Communication
medium

Backend for Frontend (BFF)

Create separate backend services for different frontend applications

Use Case:

When different clients have different data and API requirements

Pros:

  • +Optimized for specific clients
  • +Reduced client complexity
  • +Independent evolution

Cons:

  • -Code duplication
  • -Additional services to maintain
  • -Potential inconsistencies

Examples:

Mobile BFFWeb BFFPartner API BFF
Communication
high

Service Mesh

Infrastructure layer for service-to-service communication

Use Case:

When you need advanced traffic management and observability

Pros:

  • +Traffic management
  • +Security policies
  • +Observability

Cons:

  • -Additional complexity
  • -Performance overhead
  • -Learning curve

Examples:

IstioLinkerdConsul Connect
Service Mesh Guide
Reliability
medium

Circuit Breaker

Prevent cascading failures by monitoring service health

Use Case:

When you need to handle service failures gracefully

Pros:

  • +Prevents cascading failures
  • +Fast failure detection
  • +Automatic recovery

Cons:

  • -Additional complexity
  • -Configuration overhead
  • -Potential false positives

Examples:

Netflix HystrixResilience4jPolly (.NET)
Reliability
medium

Bulkhead

Isolate resources to prevent total system failure

Use Case:

When you need to isolate critical resources from failures

Pros:

  • +Fault isolation
  • +Resource protection
  • +Better availability

Cons:

  • -Resource overhead
  • -Complex configuration
  • -Potential underutilization

Examples:

Separate thread poolsConnection pool isolationCPU/Memory partitioning
Observability
medium

Distributed Tracing

Track requests across multiple services

Use Case:

When you need to debug and monitor distributed systems

Pros:

  • +End-to-end visibility
  • +Performance analysis
  • +Debugging capabilities

Cons:

  • -Performance overhead
  • -Storage requirements
  • -Complex setup

Examples:

JaegerZipkinAWS X-Ray
Observability
low

Health Check API

Provide endpoints for monitoring service health

Use Case:

When you need to monitor service availability and health

Pros:

  • +Service health visibility
  • +Automated monitoring
  • +Load balancer integration

Cons:

  • -Additional endpoints to maintain
  • -Potential security exposure
  • -False positive/negative risks

Examples:

/health endpoint/health/ready endpoint/health/live endpoint
Anti-Patterns
high

Distributed Monolith

Microservices that are tightly coupled and must be deployed together

Use Case:

Anti-pattern to avoid - services should be independently deployable

Pros:

  • +None - this is an anti-pattern

Cons:

  • -Tight coupling
  • -Deployment dependencies
  • -Reduced benefits of microservices

Examples:

Services sharing databasesSynchronous call chainsShared libraries with breaking changes
Anti-Patterns
medium

Chatty Interfaces

Services making too many fine-grained calls to each other

Use Case:

Anti-pattern to avoid - design coarse-grained interfaces

Pros:

  • +None - this is an anti-pattern

Cons:

  • -Poor performance
  • -Network overhead
  • -Increased latency

Examples:

Multiple API calls for single operationFine-grained data retrievalExcessive service-to-service communication

Pattern Categories Summary

2 / 0
Decomposition
Patterns / Anti-Patterns
2 / 1
Data Management
Patterns / Anti-Patterns
3 / 0
Communication
Patterns / Anti-Patterns
2 / 0
Reliability
Patterns / Anti-Patterns
2 / 0
Observability
Patterns / Anti-Patterns
0 / 2
Anti-Patterns
Patterns / Anti-Patterns

Pro Tip: Start with decomposition patterns to define service boundaries, then apply communication and data management patterns. Always be aware of anti-patterns to avoid common pitfalls in microservices architecture.