Pattern · seen in 1 breakdown across 1 company

Shuffle Sharding

Definition

Assign each customer (or tenant, or resource) a virtual shard: a random combination of k workers drawn from a fleet of n, instead of a fixed physical shard. A poisonous or flooding customer still takes down their own combination, but because any two combinations overlap in at most a bounded number of workers, other customers lose at most part of their shard — and fault-tolerant clients that retry around a degraded worker ride through unaffected. Scope of impact drops from the shard fraction (1/shards) to roughly 1/(n choose k), which improves exponentially as the fleet grows.

The pattern converts blast radius from an infrastructure boundary into a combinatorial invariant, at usually no additional resource cost — the fleet stays fully shared; only the assignment scheme changes. It requires an assignment-aware routing layer and clients whose retries can absorb a partially degraded shard.

When it applies

01Multi-tenant services where any worker can serve any request (DNS, API front ends, queues, stateless tiers) and one tenant's poison or flood must not become everyone's outage
02Fleets where dedicated per-tenant capacity is uneconomical but per-tenant blast radius must approach single-tenant isolation
03Layered systems, recursively — sharding at multiple layers to isolate a customer's customer

Tradeoffs

The guarantee is statistical and partly lives in the client: without retries, an overlapped customer experiences the partial outage the pattern was meant to hide
Fate-sharing becomes probabilistic and pairwise-bounded rather than cleanly enumerable — incident reasoning needs the assignment map
Does not fit state-pinned workloads: when data locality binds work to nodes, cells must be physical (Discord's geometry), not virtual

The same move, 1 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Amazon (AWS)
Amazon Builders' Library
2019
This article is the original explanation of the pattern, written by the team that invented it. Each customer gets a virtual shard: a random combination of machines (2 of 8 in the small example, 4 of 2,048 in Route 53). One problem can reach at most 1 divided by the number of possible combinations, and because any two customers' sets share at most one machine, customers whose software resends failed requests keep working. Amazon extended it to several layers (recursive shuffle sharding) and released it as the open-source Route 53 Infima library. Read the breakdown →

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.