distributed-systems-patternslisted

Design and review distributed data tiers — how keys find nodes, how data survives node loss, how consistency is tuned per workload, and what storage engine each node runs under the hood. ## When to use - Designing or reviewing data placement for a horizontally scaled store (distributed cache, KV store, sharded database) - Choosing a partitioning scheme (hash vs range vs directory) or diagnosing a hot partition - Deciding whether to shard at all — climbing the scaling ladder in the right order - Tuning replication and quorums (N/W/R) to a workload's actual correctness requirement instead of one global mode - Debugging stale reads caused by replication lag (read-your-writes violations after a write) - Designing a distributed cache cluster: placement, write strategy, eviction, invalidation, hot keys, herd protection - Adding failure detection and membership (heartbeats, gossip) to a clustered service - Choosing between B-tree and LSM storage for a read-heavy vs write-heavy workload - Weighing cross-shard atomicity options (two-phase commit vs sagas) after a sharding decision - Relieving a read or throughput bottleneck with materialized views or batching before reaching for a reshard - Explaining why adding or removing one node reshuffled keys, wiped a cache tier, or overloaded a neighbor Scope boundary — this skill owns **data placement and replication mechanics**. Adjacent territory is owned elsewhere: - The partition trade-off itself (CAP/PACELC), clock/ordering correctnes