Quick Reference

Essential Patterns and Practices for Microservices Architecture

This quick reference provides at-a-glance guidance for common microservices patterns, best practices, and decision points. Use this as a handy reference during design sessions, code reviews, and architectural discussions.

πŸ—οΈ Design Principles

Core Principles Checklist

Adaptive Granularity Strategy Decision Matrix

Factor Fine-Grained Medium-Grained Coarse-Grained
Complexity High Medium Low
Change Frequency High Medium Low
Team Capacity Multiple Teams Single Team Shared Team
Scaling Needs Independent Moderate Uniform
Data Coupling Low Medium High

Decision Rule: Choose granularity based on your organizational context, not rigid rules.

πŸ“‘ Communication Patterns

Synchronous vs Asynchronous

Aspect Synchronous Asynchronous
Coupling Higher Lower
Latency Direct Indirect
Resilience Lower Higher
Complexity Lower Higher
Use Cases Real-time queries Event processing

Communication Pattern Selection

1
2
3
4

Query Data β†’ REST/GraphQL
Commands β†’ Async Messages
Events β†’ Event Streaming
Real-time β†’ WebSockets/gRPC

REST API Best Practices

1
2
3
4
5
6
7
8
9
10
11

# Good URLs
GET /api/v1/orders/123
POST /api/v1/orders
PUT /api/v1/orders/123
DELETE /api/v1/orders/123

# Bad URLs
GET /api/getOrder?id=123
POST /api/createOrder
PUT /api/updateOrder
DELETE /api/deleteOrder

πŸ—„οΈ Data Management Patterns

Database per Service Rules

Data Consistency Patterns

Pattern Use Case Complexity Consistency
Strong Consistency Financial transactions High Immediate
Eventual Consistency User profiles Medium Delayed
Saga Pattern Multi-service workflows High Compensating
Event Sourcing Audit trails High Event-based

CQRS Decision Tree

1
2
3
4

Need different read/write models? β†’ Yes β†’ Consider CQRS
High read/write ratio? β†’ Yes β†’ Consider CQRS
Complex queries? β†’ Yes β†’ Consider CQRS
Simple CRUD? β†’ No β†’ Skip CQRS

πŸ›‘οΈ Resilience Patterns

Essential Resilience Patterns

Pattern Purpose When to Use
Circuit Breaker Prevent cascade failures External service calls
Retry Handle transient failures Network operations
Timeout Prevent hanging requests All remote calls
Bulkhead Isolate resources Critical vs non-critical
Fallback Graceful degradation User-facing features

Circuit Breaker States

1
2
3

CLOSED β†’ Normal operation
OPEN β†’ Failing fast (no calls)
HALF-OPEN β†’ Testing recovery

Retry Strategy

1
2
3

# Exponential backoff with jitter
delay = base_delay * (2 ** attempt) + random_jitter
max_attempts = 3

πŸ” Service Discovery

Discovery Patterns

Pattern Pros Cons Best For
Client-Side Simple, fast Client complexity Internal services
Server-Side Client simplicity Additional hop External clients
Service Mesh Rich features Operational complexity Large deployments

Health Check Endpoints

1
2
3
4
5
6
7
8

GET /health
{
  "status": "UP",
  "checks": {
    "database": "UP",
    "external-service": "DOWN"
  }
}

πŸ” Security Patterns

Authentication & Authorization

1

API Gateway β†’ JWT Validation β†’ Service Authorization

Security Checklist

JWT Token Structure

1
2
3
4
5
6
7
8
9
10
11
12

{
  "header": {
    "alg": "RS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "user123",
    "iat": 1516239022,
    "exp": 1516242622,
    "roles": ["user", "admin"]
  }
}

πŸ“Š Observability

Three Pillars of Observability

  1. Metrics β†’ What is happening?
  2. Logs β†’ Why is it happening?
  3. Traces β†’ Where is it happening?

Essential Metrics

Type Examples Purpose
Business Orders/minute, Revenue Business health
Application Response time, Error rate App performance
Infrastructure CPU, Memory, Disk Resource usage

Distributed Tracing

1
2
3
4
5
6

Request ID: 12345
β”œβ”€β”€ Service A (10ms)
β”œβ”€β”€ Service B (50ms)
β”‚   β”œβ”€β”€ Database Query (30ms)
β”‚   └── External API (15ms)
└── Service C (25ms)

Log Levels

1
2
3
4

ERROR β†’ System errors, exceptions
WARN β†’ Potential issues, degraded performance
INFO β†’ Important business events
DEBUG β†’ Detailed diagnostic information

πŸš€ Deployment Patterns

Deployment Strategies Comparison

Strategy Downtime Risk Complexity Rollback
Blue-Green None Low Medium Instant
Canary None Very Low High Gradual
Rolling None Medium Low Gradual
Recreate Yes High Low Manual

Container Best Practices

1
2
3
4
5
6
7
8
9
10
11
12
13

# Multi-stage build
FROM node:16-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
USER node
CMD ["npm", "start"]

Kubernetes Deployment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    spec:
      containers:
      - name: my-service
        image: my-service:v1.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080

πŸ§ͺ Testing Strategies

Testing Pyramid for Microservices

1
2
3
4
5

    /\
   /  \  E2E Tests (Few)
  /____\
 /      \ Integration Tests (Some)
/__________\ Unit Tests (Many)

Test Types

Test Type Scope Speed Cost Purpose
Unit Single function Fast Low Logic validation
Integration Service boundaries Medium Medium Interface validation
Contract API contracts Fast Low API compatibility
E2E Full workflow Slow High User journey validation

Contract Testing

1
2
3
4
5
6
7
8
9
10
11

# Consumer contract
interactions:
- description: "Get user by ID"
  request:
    method: GET
    path: /users/123
  response:
    status: 200
    body:
      id: 123
      name: "John Doe"

⚠️ Anti-Patterns to Avoid

Common Anti-Patterns

Anti-Pattern Description Solution
Distributed Monolith Tightly coupled services Proper service boundaries
Chatty Services Too many service calls Coarser-grained interfaces
Shared Database Multiple services, one DB Database per service
Lack of Automation Manual deployments CI/CD pipelines
Premature Decomposition Too many small services Start with monolith

Warning Signs

🚨 Red Flags:

πŸ“ Sizing Guidelines

Service Size Indicators

Too Small (Nano-service):

Too Large (Mini-monolith):

Just Right:

Team Size Rule

1
2

Team Size = 2-8 people (Amazon's "Two Pizza Rule")
Services per Team = 1-3 services

πŸ”§ Technology Stack Recommendations

Java Ecosystem:

1
2
3

Spring Boot + Spring Cloud
Netflix OSS (Eureka, Hystrix, Zuul)
Apache Kafka + Docker + Kubernetes

Node.js Ecosystem:

1
2

Express.js + Consul
RabbitMQ + Docker + Kubernetes

Polyglot Approach:

1
2
3
4

API Gateway: Kong/Ambassador
Service Mesh: Istio/Linkerd
Monitoring: Prometheus + Grafana
Logging: ELK Stack

πŸ“‹ Decision Checklists

Microservices Readiness Checklist

Organizational Readiness:

Technical Readiness:

Service Boundary Checklist

🎯 Quick Wins

Start Here (Low Risk, High Value)

  1. Extract Read-Only Services: Start with services that only read data
  2. Implement API Gateway: Centralize cross-cutting concerns
  3. Add Health Checks: Enable better monitoring and deployment
  4. Implement Circuit Breakers: Improve system resilience
  5. Centralize Logging: Improve observability

Avoid These Initially (High Risk)

  1. Distributed Transactions: Complex and error-prone
  2. Event Sourcing: High complexity for beginners
  3. Fine-Grained Services: Start coarser, refine later
  4. Custom Service Mesh: Use proven solutions first

πŸ“š Essential Resources

Must-Read Books

  1. β€œBuilding Microservices” - Sam Newman
  2. β€œMicroservices Patterns” - Chris Richardson
  3. β€œDomain-Driven Design” - Eric Evans

Key Websites

Tools to Evaluate

πŸ†˜ Troubleshooting Guide

Common Issues and Solutions

Problem Symptoms Solution
Cascade Failures Multiple services failing Implement circuit breakers
Slow Responses High latency Add caching, optimize queries
Data Inconsistency Stale data Implement eventual consistency
Deployment Issues Failed deployments Improve health checks
Monitoring Gaps Unknown system state Add distributed tracing

Performance Optimization

  1. Cache Frequently Accessed Data
  2. Use Async Communication Where Possible
  3. Implement Connection Pooling
  4. Optimize Database Queries
  5. Use CDN for Static Content

This quick reference is designed to be printed or bookmarked for easy access during development. For detailed explanations, refer to the full chapters in this book.

Last Updated: February 2026