Microservices design patterns

Microservices break applications into small, independent services. This solves scaling and deployment problems, but introduces distributed systems complexity. I've built microservices architectures that scaled beautifully, and I've seen microservices that became maintenance nightmares. The difference? Using the right patterns.

When to Use Microservices

Microservices aren't always the answer. I've seen teams break monolithic applications into microservices prematurely, creating more problems than they solved.

Use microservices when:

• Different parts of your application have different scaling requirements
• Teams need to deploy independently
• You have clear service boundaries
• You have the operational maturity to manage distributed systems

I've seen successful microservices architectures where services were organized by business capability (user management, order processing, inventory) rather than technical layers (database, API, frontend).

API Gateway Pattern

An API Gateway is a single entry point for client requests. It handles routing, authentication, rate limiting, and request/response transformation.

I've implemented API Gateways using:

• AWS API Gateway
• Kong
• Nginx
• Zuul (Spring Cloud)

The API Gateway provides:

• Single entry point: Clients don't need to know about individual services
• Authentication: Centralized authentication and authorization
• Rate limiting: Protect services from excessive load
• Request routing: Route requests to appropriate services
• Response aggregation: Combine responses from multiple services

For a client application, the API Gateway reduced client complexity significantly. Instead of clients calling multiple services, they call the gateway, which handles routing and aggregation.

Service Discovery

In microservices architectures, services need to find each other. Service discovery enables this.

I've used:

• Client-side discovery: Clients query a service registry and load balance requests
• Server-side discovery: Load balancer queries service registry and routes requests

Service discovery tools:

• Consul (HashiCorp)
• Eureka (Netflix, Spring Cloud)
• Kubernetes DNS (built-in service discovery)
• Zookeeper

Kubernetes provides service discovery automatically. Services register with Kubernetes, and DNS resolution handles routing. This simplifies microservices deployment significantly.

Circuit Breaker Pattern

When a service fails, cascading failures can bring down entire systems. Circuit breakers prevent this.

A circuit breaker has three states:

• Closed: Normal operation, requests pass through
• Open: Service is failing, requests fail immediately without calling service
• Half-open: Testing if service has recovered, allowing limited requests

I've implemented circuit breakers using:

• Hystrix (Netflix, now deprecated but concepts remain)
• Resilience4j (Java)
• Custom implementations

For a payment processing service, circuit breakers prevented payment failures from cascading to other services. When the payment service failed, the circuit opened, and requests failed fast instead of timing out.

Event-Driven Architecture

Event-driven architecture uses events to communicate between services. Services publish events when something happens, and other services subscribe to events they care about.

I've implemented event-driven architectures using:

• AWS EventBridge / SNS / SQS
• Apache Kafka
• RabbitMQ
• Redis Pub/Sub

Event-driven architecture provides:

• Loose coupling: Services don't need to know about each other
• Scalability: Services can scale independently
• Resilience: If a service is down, events queue until it recovers
• Flexibility: Easy to add new services that react to events

For an e-commerce platform, order events triggered inventory updates, email notifications, and shipping preparation. Adding new functionality meant subscribing to events—no changes to existing services.

Database per Service

Each microservice should have its own database. This ensures services are truly independent.

Database per service provides:

• Independence: Services can use different database technologies
• Scalability: Scale databases independently
• Isolation: Failures don't cascade through shared databases

Challenges:

• Data consistency: Maintaining consistency across services requires patterns like Saga
• Queries: Joining data across services requires API calls or event sourcing
• Transactions: Distributed transactions are complex

I've used the Saga pattern for distributed transactions. Instead of two-phase commit, Sagas use a sequence of local transactions with compensating actions if something fails.

Saga Pattern

The Saga pattern manages distributed transactions. Instead of a single distributed transaction, Sagas use a sequence of local transactions.

If a step fails, compensating transactions undo previous steps. I've implemented Sagas for order processing:

1. Create order (Order Service)
2. Reserve inventory (Inventory Service)
3. Charge payment (Payment Service)
4. If payment fails, release inventory and cancel order

Sagas can be:

• Choreography-based: Services coordinate through events
• Orchestration-based: A central orchestrator coordinates steps

I prefer orchestration for complex workflows because it's easier to understand and debug.

Bulkhead Pattern

The bulkhead pattern isolates resources to prevent failures from cascading. Like ship bulkheads that prevent flooding from spreading.

I implement bulkheads by:

• Separate thread pools for different operations
• Separate connection pools for different services
• Isolated resources (CPU, memory) for critical services

For a web application, I separated thread pools for user requests and background jobs. When background jobs consumed resources, user requests weren't affected.

Service Mesh

Service meshes handle cross-cutting concerns like service discovery, load balancing, and security. They're implemented as sidecar proxies alongside each service.

I've used:

• Istio
• Linkerd
• AWS App Mesh

Service meshes provide:

• Traffic management (routing, load balancing)
• Security (mTLS, authentication)
• Observability (metrics, tracing, logging)

Service meshes add complexity but provide powerful capabilities. I use them when the benefits outweigh the operational overhead.

What I've Learned

After building microservices architectures:

• Start with a monolith. Extract microservices when you have clear boundaries.
• Use patterns strategically. Not every pattern is needed for every system.
• Invest in observability. Distributed systems are hard to debug without proper monitoring.
• Design for failure. Services will fail—design systems that handle failures gracefully.
• Keep services focused. Small, focused services are easier to understand and maintain.

Microservices solve real problems, but they introduce complexity. Use patterns to manage that complexity, and invest in the operational capabilities needed to run distributed systems successfully.