2. Saga #pattern
A saga is a series of local transactions. In #microservices #applications, a saga pattern can help maintain #data consistency during distributed transactions.

3. API gateway pattern
For large applications with multiple clients, implementing an #API gateway #pattern is a compelling option One of the largest benefits is that it insulates the client from needing to know how services have been partitioned.

4. Aggregator design pattern

An aggregator design #pattern is used to collect pieces of #data from various microservices and returns an aggregate for processing. Although similar to the backend-for-frontend (BFF) design pattern, an aggregator is more generic and not explicitly used for UI.

5. Circuit breaker design pattern

This #pattern is usually applied between services that are communicating synchronously. A developer might decide to utilize the circuit breaker when a #service is exhibiting high latency or is completely unresponsive. The utility here is that failure across multiple systems is prevented when a single #microservice is unresponsive. Therefore, calls won’t be piling up and using the system resources, which could cause significant delays within the app or even a string of service failures.

6. Command query responsibility segregation (CQRS)

A developer might use a command query responsibility segregation (CQRS) design #pattern if they want a solution to traditional #database issues like #data contention risk. CQRS can also be used for situations when app #performance and #security are complex and objects are exposed to both reading and writing transactions.

7. Asynchronous messaging

If a #service doesn’t need to wait for a response and can continue running its code post-failure, asynchronous messaging can be used. Using this design #pattern, microservices can communicate in a way that’s fast and responsive. Sometimes this pattern is referred to as event-driven communication.

8. Event sourcing

The #event sourcing design #pattern is used in microservices when a developer wants to capture all changes in an entity’s state. Using event stores like Kafka or alternatives will help keep track of event changes and can even function as a message broker. A message broker helps with the communication between different microservices, #monitoring messages and ensuring communication is reliable and stable.

9. Strangler

Developers mostly use the strangler design #pattern to incrementally transform a #monolith #application to microservices. This is accomplished by replacing old functionality with a new #service — and, consequently, this is how the pattern receives its name. Once the new service is ready to be executed, the old service is “strangled” so the new one can take over.

1. Single Container Pattern 📦

The Single #Container #Pattern is the simplest form of #containerization. It involves packaging an entire #application, along with its dependencies, into a single container.

2. Sidecar Pattern 🚗

The Sidecar #Pattern introduces a secondary #container, known as a sidecar, alongside the main #application container. This sidecar container extends or enhances the functionality of the primary container without affecting its core logic. This pattern is valuable for tasks such as #logging 📝, #monitoring 📊, or handling additional responsibilities.

3. Ambassador Pattern 🤝

The Ambassador #Pattern focuses on communication between #microservices within a containerized #application. It utilizes an ambassador container to manage network-related concerns, such as routing and load balancing, abstracting the complexities from the main application containers. 🌐

4. Adapter Pattern 🔄

The Adapter #Pattern is employed when integrating legacy systems with modern #containerized #applications. It acts as a bridge, allowing the legacy components to communicate seamlessly with containerized services. This pattern is crucial for organizations undergoing digital transformation. 🚀