Partitioning or Sharding¶

A domain-division method — instantiates Scalable Architecture Design

Splits one too-large shared domain into disjoint slices by a chosen key, so each slice is owned and served independently and no single unit must hold the whole.

Partitioning or Sharding attacks a different limit than adding units does: not "we need more throughput" but "the domain itself — the data, the territory, the caseload — has grown too large for any one unit to hold." The defining move is choosing a partition key and using it to divide the domain into disjoint slices, each assigned to its own unit that owns that slice completely. Unlike interchangeable scale-out, the units here are not interchangeable — shard 3 holds different data than shard 7, and a request must be routed to the one that owns its key. This is how you scale a thing that can't simply be copied, at the cost of a new problem: everything now depends on the key being chosen well.

Example¶

A B2B SaaS product's single database has grown past what one server can hold or index quickly; the customers table alone is enormous and every query is slowing. The team shards. They pick a partition key — customer account ID — and split the data into, say, sixteen shards, each a separate database holding a disjoint set of accounts. A routing layer hashes each request's account ID to the shard that owns it, so a query touches one-sixteenth of the data and runs fast again.

The win is real: capacity for data and queries now grows by adding shards. But the key choice bites almost immediately. One enterprise customer is 50× larger than the rest, so its shard runs hot while others idle — a "hot shard." And a report that needs to span all customers can no longer be a single query; it must fan out to sixteen shards and merge. Those two costs — skew and cross-shard operations — are the permanent tax of the design, and choosing a better key (or isolating the whale) is the ongoing work.

How it works¶

Choose the partition key. Pick the attribute that divides the domain into disjoint, independently-servable slices — account, region, hash of an ID, date range. This single choice determines the design's success more than anything else.
Route by key. A routing layer maps each request to the shard that owns its key, so callers reach the right slice without knowing the layout. Shards do not share data, which is what lets each scale on its own.
Rebalance as slices grow uneven. A rule governs when to split a shard, add shards, or move keys, because real-world keys distribute unevenly over time.
Contain cross-partition work. Operations that span slices (global reports, cross-account transactions) are the expensive exception; the design names them and handles them by scatter-gather or by keeping them rare.

Tuning parameters¶

Partition key — the axis of the split. A key with even, stable distribution avoids hot slices; a convenient-but-skewed key concentrates load and undoes the benefit. This is the master dial.
Shard count and size — many small shards spread load finely and rebalance easily but multiply routing and cross-shard fan-out; few large ones are simpler but coarser and quicker to overflow.
Rebalancing strategy — range splits, consistent hashing, or manual moves, trading rebalance smoothness against routing complexity and data-movement cost.
Cross-partition tolerance — how much the design permits operations that span slices. Allowing more is convenient but reintroduces the coupling sharding was meant to remove.
Isolation of outliers — whether abnormally large keys get their own dedicated slice, protecting the rest at the cost of bespoke handling.

When it helps, and when it misleads¶

Its strength is scaling a domain that is too big to hold or too large to search as a whole — data, territory, caseload — by dividing it so each part is served independently. It fits precisely when the size of the domain, not the volume of identical work, is the binding constraint.

It misleads when the partition key is chosen badly. A skewed key produces hot slices that saturate while others idle, so the average looks fine while a few keys carry all the pain^[1] — and re-keying a live, populated system is one of the most painful migrations there is. The design also makes any operation that spans slices expensive and any cross-slice consistency hard, so applying it to a domain whose access patterns are inherently global buys division cost for no gain. The classic misuse is sharding to look scalable before the domain is actually the bottleneck, or picking the key that's easy today rather than the one that distributes evenly under real load. The discipline is to derive the key from actual access patterns, plan for skew and outliers up front, and confirm that cross-partition operations are genuinely the rare case before committing.

How it implements the components¶

replication_or_partitioning_rule — realizes the rule as partitioning: divide the domain by key into disjoint slices, with a defined trigger for when to split or add a shard.
scaling_dimension — names the growth being absorbed as growth of the domain itself (data volume, territory, caseload), distinguishing it from growth in identical work.
degradation_mode_map — maps the design's characteristic failure shapes — hot shards, cross-partition fan-out, rebalance storms — so they are anticipated rather than discovered in production.
load_distribution_layer — the key-based router that sends each request to the shard owning its slice; unlike an even-spread balancer, it routes by ownership.

It does not add interchangeable units of the same work — that even-spread growth is Horizontal Scale-Out's — and it does not define the network contracts and partial-failure handling between the resulting services, which is Distributed Service Model's.

Instantiates: Scalable Architecture Design — supplies the "divide a too-large domain by key" growth shape.
Sibling mechanisms: Horizontal Scale-Out · Distributed Service Model · Cloud Scaling Pattern · Resource Pooling · Vertical Scale-Up · Modular Architecture · Service Decomposition · Platform Core / Extension Model · Franchise-like Replication · Standardized Rollout Template · Scalable Governance Cadence

Notes¶

Partitioning divides a domain into non-interchangeable slices routed by key; scale-out multiplies interchangeable units and spreads work evenly. The two are complementary and often combined — each shard is itself scaled out into replicas — but confusing them leads to the wrong distributor: an even-spread balancer in front of shards will send requests to units that don't own the data.

References¶

[1] Partition skew (also "hotspotting"): when the partition key concentrates disproportionate data or traffic on a few shards, those slices saturate while the rest sit idle — the dominant failure mode of a sharded design and the reason key choice outweighs shard count. ↩