Mostly Used Distributed System Patterns

Here is the brief explanation of 7 mostly used Distributed System Design Patterns.

1. Ambassador

The first is the "Ambassador". Think yourself as a manager and your assistant who is handling all your appointments and communication. Thats exactly what Ambassador pattern does for your application. It acts as a bridge for your app the services it communicates with. Offloading tasks as logging, monitoring or handling retries.

For example, Kubernetes uses envoy as Ambassador to simplify communication between services.

This is not to be used when de-coupling your legacy/monolithic application. Use this when you want to add new features to the legacy but you don't want to touch the legacy system.

2. Circuit Breaker

This is a popular pattern for fault tolerance in microservices. When a service becomes unavailable, the Circuit Breaker stops requests, allowing it to recover.

The Circuit Breaker pattern works by wrapping a potentially dangerous or faulty operation in a circuit breaker object. The circuit breaker is designed to detect when the operation is failing or taking too long to complete.?

Generally following steps are taken:

1. Detect something is wrong
2. Take temporary steps to avoid the situation getting worse
3. Deactivate the problem component so that it does not affect the downstream components.

When does the circuit trip?

• Last N requests to consider for the decision
• How many of those should fail
• Timeout duration

3. CQRS(Command Query Responsibility Segregation)

CQRS is like having restaurant with separate lines for ordering food and picking up orders.

By separating the write or command,?and read or query operations we can scale and optimise each independently.

An ecommerce platform might have?high read requests for products listings but fewer write requests for placing orders. CQRS allows each operation to be handled efficiently. This pattern becomes especially valuable in systems where read and write operations have different performance characteristics, with different latency or resource requirements

Command is referred to as write(Create, Update, Delete) operations and query is referred to as read operations.

This pattern basically suggests segregating the write operations from read operations because we usually have fewer write queries as compared to read queries.

4. Event Sourcing

Think of Event Sourcing as keeping the journal of life events. Instead of updating the record directly, we store events representing changes.

A banking application is an ideal scenario where we can implement Event Sourcing pattern. A customer starts with $100 in his bank account. That hundred dollar is stored in a column "total_amount = $100". If a customer withdraws $50, and the total_amount is calculated as $100 - $50 = $50 and the column is updated with $50 value. This update action, replaces the value $100 with $50 and now querying the database tells us the final amount but it doesn't tell us how we got there.

The customer might have withdrawn $20 and $30 or he might withdraw $90 and then deposited $70 but we don't know the complete trail.

So, the idea is instead of updating a record directly, we store events representing changes. This approach provides a complete history of the system and enables better auditing and debugging. Git version control is a great example of Event Sourcing, where each commit represents a change.

5. Sharding

Sharding is like dividing a large pizza into smaller slices, making it easier to handle. It's a technique for distributing data across multiple nodes in a system. It improves performance and scalability. Each shard contains a subset of data, reducing the load on any single node.

Databases like MongoDB and Cassandra use sharding to handle large amounts of data efficiently.