8 Must-Know Distributed System Design Patterns

The page presents eight distributed system patterns and frames them as responses to state management, failures, and communication between services. It says these patterns help build scalable, fault-tolerant, and highly available systems.

Reading notes

#

• The Ambassador Pattern offloads non-business-critical tasks to a helper service that acts as a proxy between the application and external services or infrastructure.
• It handles repetitive and cross-cutting work such as retries, logging, monitoring, and circuit breaking, keeping the main service lightweight.
• The Circuit Breaker Pattern monitors service calls and stops requests when failures pass a threshold, then tests recovery after a cooldown period.
• It protects downstream dependencies, isolates failing components, and reduces unnecessary traffic to struggling services.
• CQRS separates write operations from read operations, using different models for each.
• The query side can use precomputed, denormalized views for efficient reads, while the command side handles creating or updating data.
• Sharding splits a database into smaller partitions distributed across servers, with each shard holding a subset of the data.
• It partitions data by a key such as user ID or geographical region to improve horizontal scalability and reduce contention.
• The Sidecar Pattern deploys auxiliary containers alongside the main service to handle concerns like service discovery, logging, monitoring, and configuration management.
• Pub/Sub enables asynchronous communication between publishers and subscribers through topics or event streams managed by a message broker.
• It decouples producers and consumers and supports real-time streaming and multiple consumers for the same event.
• The Leader Election Pattern ensures that only one node takes a coordination role at a time, often through consensus algorithms like Raft or Paxos.
• It prevents conflicts, simplifies coordination, and allows a new leader to be elected if the current one fails.
• Event Sourcing stores state changes as immutable events in an event store instead of storing current state directly.
• Those events can be replayed to reconstruct state, provide an audit log, and support CQRS query models.