Most-Used Distributed System Design Patterns

Distributed system design patterns provide architects and developers with proven solutions and best practices for designing and implementing distributed applications.

Ambassador — Proxy

The ambassador pattern focuses on offloading all the major tasks that are critical to applications other than business logic so that applications can focus only on critical use cases.

Circuit Breaker

Imagine a water pipe breaks down the house, the first thing we should do is shut down the main valve to prevent further damage. the circuit breaker pattern works similarly preventing cascading failures in distributed systems.

CQRS (Command Query Responsibility Segregation)

CQRS separates reads and writes into different databases, Commands perform update data, and Queries perform read data.

An E-Commerce platform might have high read requests for product listings but fewer write requests for placing orders.

Event Sourcing

Think of event sourcing as keeping a journal of the live events. Instead of storing the current state of data, this pattern records a sequence of events that led to the current state.

Sidecar Pattern

Deploys auxiliary components (sidecars) alongside the main service containers to manage cross-cutting concerns like logging, monitoring, and configuration.

Leader Selection

In distributed systems, some tasks need a single leader. Leader election algorithms ensure one node is designated as the leader.

In this pattern, it ensures that only one node is responsible for a specific task or resource.

Publisher/Subscriber

This pattern allows services to communicate asynchronously. Publishers send messages without the knowledge of subscribers, and subscribers receive messages of interest.

For Example, The publisher/subscriber pattern is like a newspaper delivery service, publishers emit events without knowing how many subscribers receive them, and subscribers listen for events they are interested in.

Sharding

Divides a dataset into smaller, more manageable pieces (shards) that can be distributed across multiple databases or nodes.

Sharding is like dividing a large pizza into smaller slices, making it easier to handle.

Bulkhead

Isolates components in a system so that a failure in one component does not cause a system-wide failure.

The Bulkhead Pattern is particularly useful in the following scenarios:

1. Resource Isolation: When you need to isolate resources used by consumer backend services to prevent resource contention.
2. Critical Consumer Isolation: To shield critical consumers (services) from standard consumers, ensuring the availability and responsiveness of critical services even during peak loads or failures.
3. Cascading Failure Protection: To safeguard your application from cascading failures that can occur when issues in one service affect others.

Cache-Aside

This pattern involves explicitly loading data into a cache from the data store and writing data to the data store through the cache.

Write-Through and Write-Behind Caching

Write-through caching involves writing data to both the cache and the primary data source simultaneously.

Read-Through and Read-Ahead Caching

Read-through caching involves reading data from the cache. If the data is not found, it’s retrieved from the primary data source, stored in the cache, and returned to the user.

Read more : https://medium.com/javarevisited/most-used-distributed-system-patterns-d5d90ffedf33