Skip to main content
Aggregator Microservices

Intent

The user makes a single call to the aggregator service, and the aggregator then calls each relevant microservice.

Explanation

Real world example

Our web marketplace needs information about products and their current inventory. It makes a call to an aggregator
service which in turn calls the product information microservice and product inventory microservice returning the
combined information.


iluwatarAbout 1 minArchitecturalCloud distributedDecouplingMicroservices
Ambassador

Intent

Provide a helper service instance on a client and offload common functionality away from a shared resource.

Explanation

Real world example

A remote service has many clients accessing a function it provides. The service is a legacy application and is
impossible to update. Large numbers of requests from users are causing connectivity issues. New rules for request
frequency should be implemented along with latency checks and client-side logging.


iluwatarAbout 2 minStructuralDecouplingCloud distributed
API Gateway

Intent

Aggregate calls to microservices in a single location, the API Gateway. The user makes a single call
to the API Gateway, and the API Gateway then calls each relevant microservice.

Explanation

With the Microservices pattern, a client may need data from multiple different microservices. If the
client called each microservice directly, that could contribute to longer load times, since the
client would have to make a network request for each microservice called. Moreover, having the
client call each microservice directly ties the client to that microservice - if the internal
implementations of the microservices change (for example, if two microservices are combined sometime
in the future) or if the location (host and port) of a microservice changes, then every client that
makes use of those microservices must be updated.


iluwatarAbout 2 minArchitecturalCloud distributedDecouplingMicroservices
Caching

Intent

The caching pattern avoids expensive re-acquisition of resources by not releasing them immediately
after use. The resources retain their identity, are kept in some fast-access storage, and are
re-used to avoid having to acquire them again.

Explanation

Real world example


iluwatarAbout 4 minBehavioralPerformanceCloud distributed
Circuit Breaker

Intent

Handle costly remote service calls in such a way that the failure of a single service/component
cannot bring the whole application down, and we can reconnect to the service as soon as possible.

Explanation

Real world example

Imagine a web application that has both local files/images and remote services that are used for
fetching data. These remote services may be either healthy and responsive at times, or may become
slow and unresponsive at some point of time due to variety of reasons. So if one of the remote
services is slow or not responding successfully, our application will try to fetch response from
the remote service using multiple threads/processes, soon all of them will hang (also called
thread starvation) causing our entire web application to crash. We should be able to detect
this situation and show the user an appropriate message so that he/she can explore other parts of
the app unaffected by the remote service failure. Meanwhile, the other services that are working
normally, should keep functioning unaffected by this failure.


iluwatarAbout 5 minBehavioralPerformanceDecouplingCloud distributed
Commander

Intent

Used to handle all problems that can be encountered when doing distributed transactions.

Class diagram

Commander class diagram

Applicability

This pattern can be used when we need to make commits into 2 (or more) databases to complete transaction, which cannot be done atomically and can thereby create problems.


iluwatarLess than 1 minuteConcurrencyCloud distributed
CQRS

Intent

CQRS Command Query Responsibility Segregation - Separate the query side from the command side.

Class diagram

CQRS

Applicability

Use the CQRS pattern when

  • You want to scale the queries and commands independently.
  • You want to use different data models for queries and commands. Useful when dealing with complex domains.
  • You want to use architectures like event sourcing or task based UI.

iluwatarLess than 1 minuteArchitecturalPerformanceCloud distributed
Event Sourcing

Intent

Instead of storing just the current state of the data in a domain, use an append-only store to record the full series of actions taken on that data. The store acts as the system of record and can be used to materialize the domain objects. This can simplify tasks in complex domains, by avoiding the need to synchronize the data model and the business domain, while improving performance, scalability, and responsiveness. It can also provide consistency for transactional data, and maintain full audit trails and history that can enable compensating actions.


iluwatarLess than 1 minuteArchitecturalPerformanceCloud distributed
Leader Election

Intent

Leader Election pattern is commonly used in cloud system design. It can help to ensure that task instances select the leader instance correctly and do not conflict with each other, cause contention for shared resources, or inadvertently interfere with the work that other task instances are performing.


iluwatarLess than 1 minuteBehavioralCloud distributed
Poison Pill

Intent

Poison Pill is known predefined data item that allows to provide graceful shutdown for separate
distributed consumption process.

Explanation

Real world example

Let's think about a message queue with one producer and one consumer. The producer keeps pushing
new messages in the queue and the consumer keeps reading them. Finally when it's time to
gracefully shut down the producer sends the poison pill message.


iluwatarAbout 2 minBehavioralCloud distributedReactive
2