What Are Microservices Design Patterns?
Microservices design patterns are for developers and technology professionals to implement standardized solutions and best practices in distributed systems. Because microservices split what is traditionally a single application into multiple moving parts, you’ll need to design a system with consistent data and user behaviors. You’ll also need to ensure that one failing service doesn’t crash other services or even the whole system. These patterns provide you with the design framework you’ll need.
Decomposition Patterns
Decomposition patterns help you determine how to break up a large, monolithic application into smaller, more manageable services. Let’s look at three of these patterns:
- Decompose by Business Capability: Organize services around the business goals and application capabilities. For example, name and design a “Claims” service for an insurance-focused application. Name and design “Ordering” and “Shipping” services for an e-commerce application. Name and design a “Fraud Detection” service to analyze financial transactions and flag suspicious activities.
- Decompose by Subdomain: This is a practical design method, where you group services by your bounded domain contexts to ensure that each of your internal data models don’t leak into each other. Subdomains can be classified into prioritization groups, including the core subdomains (the part of the system that provide a competitive advantage and require the highest performance), the supporting subdomains (necessary for the business but don’t provide a business advantage, such as an internal tool), and generic subdomains (standard across all your businesses and can be bought as standalone software, such as email or authentication services).
- Strangler Fig Pattern: This pattern is used to gradually transition from a monolithic application design to microservices. You build your new features as microservices and then you “strangle” the monolith by replacing its capabilities and functions one by one until it’s completely replaced (and retired) by your microservices solution. This is a great method if you want to migrate to microservices, but you don’t have the time, budget, or resources to do so. Instead, you migrate gradually over time.
Communication Patterns
Communication patterns define how external clients interact with your system and how your different microservices integrate with each other. Here are some of these patterns to consider:
- API Gateway: A common pattern (with PaaS cloud services built for you to implement it), you build a single entry point that handles your routing, authentication, and rate limiting. The advantage of this pattern is that it prevents the client from knowing the location of the individual services.
- Backend for Frontend: A variation of the API Gateway, where you create a separate gateway for each client, to optimize the data that they receive. For example, you might have one gateway for your mobile app and one for your web client.
- Aggregator: This is a service that collects data from multiple other services and combines the data into a single response. It reduces the number of network calls that a client has to make.
- Service Discovery: This pattern is also considered an orchestration and management pattern, but you can’t communicate with your other services if you can’t find them! This is a “live contact list” for your microservices. It builds a service registry as a central database to track the IP address and port of every service at any given moment. When the service starts, it tells the registry where the service is. When one service needs to use another (such as the “Order” service needs to process a payment using the “Payment” service, then the registry sends back the IP location of the Payment service to the Order service.
Database Patterns
Database patterns allow each of your microservices to own its own data, in order to operate independently. However, you need the services to interact as one cohesive unit, so that they share consistent and accessible data in transactions and queries. Here are four data management patterns to consider:
- Database-per-Service: You include a private database for each of your services. This gives you an agile loose coupling, but it makes it harder for you to join data across your services.
- Saga Pattern: This pattern manages a sequence of local transactions. That way, if one step fails, then it triggers compensating transactions that undo the previous steps.
- CQRS (Command Query Responsibility Segregation): You separate your “Write” model from your “Read” model to ensure you have high-performance reads (like for a product search) that are separated from the complex logic you’ll need to update your data.
- Event Sourcing: Instead of storing just the current state of an object, you use this pattern to store every change as a sequence of events instead. You then just “replay” these events to reach any point in history. It’s like an immutable browsing history for your data.
Reliability Patterns
Reliability patterns help you build resilience in your microservices. Distributed systems (and most all systems) will fail eventually, so these three patterns help ensure that you contain each failure:
- Circuit Breaker: This pattern prevents a service from repeatedly trying to call a failing downstream service. When that happens, it “trips” the circuit and immediately returns an error, which gives your failing service time to recover.
- Bulkhead: Just like how isolated compartments in a ship help prevent the ship from sinking, this pattern isolates your resources (such as thread pools or memory) so that if one service is overwhelmed, it doesn’t automatically consume all your resources and unintentionally starve the rest of the services from your system’s resources.
- Retry: This pattern automatically retries a failed request a set number of times, which helps resolve “transient” errors like a brief or temporary network flicker.
Observability Patterns
Observability patterns can be incredibly useful if you have many services. For example, if your application runs 50 services, you can’t just look at one log file to see what went wrong. Here are three design patterns that can help:
- Log Aggregation: This pattern pulls logs from all the services into a centralized tool (such as using ELK or Splunk).
- Distributed Tracing: This pattern assigns a unique correlation ID to a request so that you can follow how the request traveled through each of your services.
- Health Check: Each service provides an endpoint (such as /health) that an orchestrator (such as Kubernetes) pings to see if the service is still alive or if it needs to be restarted.
Scalability Patterns
Scalability patterns are the blueprints that help make sure your system can handle a growing amount of work, including more users, more data, and higher transaction volumes. Your system automatically adds the necessary resources, so you don’t have to redesign the application. Let’s discuss one of these patterns in particular:
- Scale-Out: Also called horizontal scaling, when a microservice faces a surge in traffic, then a load balancer or orchestrator (like Kubernetes) detects the load pressure and triggers the creation of new, temporary “clones” of your service.
Java and Implementation Considerations
If you’re using a Java Spring Boot environment, common design patterns to start with include the API Gateway and Circuit Breaker patterns. They provide immediate protection and structure for your microservices solution.
Java developers don’t have to write these patterns from scratch. The Java ecosystem includes battle-tested libraries that help you implement many of these microservices design patterns. Here are some examples of Java tools that you can use:
| Design pattern | Java implementation or library |
|---|---|
| API Gateway | Spring Cloud Gateway |
| Circuit Breaker | Resilience4j provides annotations like @CircuitBreaker that wrap your Java methods. |
| Saga Pattern | Axon Framework or Eventuate can help you manage compensating transactions and undo logic across your different Java services. |
| CQRS | Spring Data combines with an event store like Kafka to use a Java entity for writing and a lightweight DTO (data transfer object) for reading. |
| Distributed Tracing | Micrometer Tracing automatically injects Trace IDs into your Java logs and headers. |
| Services Discovery | Spring Cloud Netflix Eureka builds a registry for locating your services. |
How Azul Prime Enhances these Patterns
While libraries like Resilience4j help handle the logic of the patterns, Azul Prime handles the execution environment. Prime helps in a few different ways:
- C4 GC prevents false Circuit Breaker trips: A Garbage Collection (GC) pause can last for seconds. An API Gateway or Circuit Breaker might think the service is dead and not responding, thus “tripping” the circuit incorrectly and cutting off a healthy service. Azul’s C4 Garbage Collector eliminates the pauses and keeps the response times quick and reliable. The Circuit Breakers would then trip when you encounter a real software or network failure, not a temporary hiccup in your JVM’s performance.
- ReadyNow! makes decomposition and scaling instant: Java’s warmup times become a major problem, if you decompose a monolith into 20 microservices, and each one starts slowly while the JIT compiler optimizes your code. Azul’s ReadyNow! technology allows your Java services to start at their peak performance, because it “remembers” the optimized state of your code. The Scale-Out pattern then works in real-time.
- Cloud Native Compiler enhances the Sidecar and Density patterns: Microservices often use Sidecars (extra containers for security or logging), which can consume a lot of CPU for JIT compilation across many smaller containers. Azul’s Cloud Native Compiler offloads the heavy lifting of code compilation to a separate server. This allows you to run individual microservices that are much smaller and leaner, packing even more services into a single server, which improves your Database-per-Service density.
- C4 GC increases the reliability of Saga and Event processing: Patterns like Saga and Event Sourcing rely on high-throughput processing of the message queues. A single GC pause in your orchestrator service can delay your entire business transaction. Azul provides a higher sustained throughput and a lower tail-end latency (the slowest 1% of the requests). This
ensureensures that multi-step patterns like Sagas finish faster with increased reliability.
Java developers building microservices can use Azul Prime to solve major performance and consistency issues that are inherent when running a distributed Java application. To learn more about how Prime can provide you with a high-performance JVM, see Azul Prime: High Performance JVM.
