Microservices architecture has become the default for building scalable, maintainable systems. But "just break it into services" is far from sufficient guidance. The real skill lies in choosing the right patterns for communication, data management, and resilience. Here are the 10 patterns every developer building distributed systems should understand.
1. API Gateway
A single entry point that routes requests to the appropriate microservice. It handles cross-cutting concerns like authentication, rate limiting, and request transformation. Tools like Kong, AWS API Gateway, and Traefik are popular choices. Without a gateway, clients need to know about every service endpoint directly — a maintenance nightmare.
2. Service Discovery
In a dynamic environment where services scale up and down, hardcoded URLs don't work. Service discovery (via Consul, Eureka, or Kubernetes DNS) lets services find each other at runtime. Client-side discovery queries a registry directly; server-side discovery uses a load balancer that queries the registry.
3. Circuit Breaker
When a downstream service is failing, you don't want cascading failures. The circuit breaker pattern (popularized by Netflix Hystrix, now implemented in Resilience4j) monitors failure rates and "opens" the circuit when a threshold is breached, returning a fallback response instead of making doomed requests.
4. Event-Driven Architecture
Instead of synchronous HTTP calls between services, events are published to a message broker (Kafka, RabbitMQ, AWS SNS/SQS). Services subscribe to events they care about and process them asynchronously. This decouples services, improves resilience, and enables event sourcing.
5. SAGA Pattern
Distributed transactions across services are hard. The SAGA pattern breaks a transaction into a sequence of local transactions, each with a compensating action for rollback. Choreography-based SAGAs use events; orchestration-based SAGAs use a central coordinator. Choose orchestration when the flow is complex.
6. CQRS (Command Query Responsibility Segregation)
Separate your read and write models. Commands (writes) go to one model optimized for consistency; queries (reads) go to another optimized for performance. This is especially powerful when combined with event sourcing, where the write side produces events that the read side materializes into queryable views.
7. Sidecar / Service Mesh
Deploy a proxy alongside each service (the "sidecar") that handles networking concerns: mTLS, retries, tracing, and load balancing. Istio, Linkerd, and Cilium are popular service mesh implementations. The application code stays simple while the mesh handles infrastructure complexity.
8. Strangler Fig
Migrating a monolith to microservices? Don't rewrite from scratch. The strangler fig pattern incrementally replaces monolith functionality with new services. Route new features to microservices and gradually move existing features over. The monolith shrinks until it can be retired.
9. Database per Service
Each microservice owns its data and exposes it only through its API. No shared databases. This ensures loose coupling and allows each service to choose the best storage technology (Postgres, MongoDB, Redis) for its needs. Data consistency across services is achieved through events or SAGAs, not shared tables.
10. Backends for Frontends (BFF)
Different clients (web, mobile, IoT) have different data needs. Instead of one API that tries to serve everyone, create a dedicated backend for each frontend. The BFF aggregates data from multiple microservices and shapes it for its specific client, reducing over-fetching and improving performance.
You can generate architecture diagrams for any of these patterns in ArchitectAI. Just describe the pattern (e.g., "event-driven architecture with Kafka, three producer services, and two consumer services") and get a professional diagram instantly.