Why one crowded shard is more dangerous than a hundred quiet ones — and how the industry arrived at the tools we use to prevent it.

Imagine a school with 1,000 students and only one teacher to check everyone’s homework. That teacher would be overwhelmed. Now imagine the school hires 10 teachers, and each teacher checks the homework of 100 students. That’s much faster and fairer — as long as the 1,000 students are split evenly, 100 per teacher.

But what happens if someone splits the students badly — say, 900 students go to Teacher A and only 10 students go to each of the other 9 teachers? Teacher A becomes overloaded while the other nine sit around with almost nothing to do. This is exactly the problem this guide is about, except instead of teachers and students, we’re talking about database servers and data.

In the world of large‑scale software systems, a single database server can only handle so many requests per second and so much data before it slows down or runs out of space. The industry’s answer to this limit is a technique called sharding — splitting one big database into many smaller pieces, called shards, and spreading them across multiple machines.

1.1 A short history of sharding

• Early 2000sWeb companies like Google, Amazon, LiveJournal, and later Facebook and Twitter outgrow what a single database server can handle. Vertical scaling (buying a bigger machine) starts hitting hard economic and physical ceilings.
• ~2004LiveJournal’s engineering team is often credited with popularizing the term “shard” when they split their user database horizontally across multiple MySQL servers — giving the industry both the name and a clear pattern.
• Mid 2000sGoogle’s Bigtable and Amazon’s Dynamo papers formalize the ideas behind auto‑partitioning, consistent hashing, and replication that inspire an entire generation of NoSQL and NewSQL databases.
• 2010sSharding becomes a built‑in feature rather than a homegrown pattern: MongoDB, Cassandra, DynamoDB, Vitess (used by YouTube and Slack), and later CockroachDB and Spanner all ship sharding as a core capability.
• TodayAlmost every serious internet‑scale system shards its primary datastore — but the same era has also produced a growing catalog of famous outages and near‑misses caused by hot partitions: the topic of this guide.

Sharding introduces a brand‑new problem that didn’t exist with a single database: if you split your data poorly, some shards become hot — meaning they receive far more traffic or store far more data than others — while other shards stay cold and underused. This imbalance is called a hot partition (also called a hot shard or hot key problem), and it is one of the most common — and most painful — mistakes in distributed system design.

This guide will teach you, from the ground up, what hot partitions are, why they happen, and the proven engineering techniques to prevent them — the same techniques used inside systems that serve billions of requests a day.

Before we can avoid hot partitions, we need to feel the pain they cause. Let’s build the problem step by step.

2.1 Why do we shard in the first place?

A single database server has physical limits:

• Storage limit — a hard disk or SSD can only hold so much data.
• CPU and memory limit — one machine can only process so many queries per second.
• Network limit — one network interface can only push so many bytes per second.

When an application grows — more users, more orders, more messages — the database eventually hits one of these limits. At that point, you have two broad choices:

1. Vertical scaling — buy a bigger, more powerful machine (more CPU, more RAM, faster disks).
2. Horizontal scaling (sharding) — split the data across many smaller, cheaper machines that work together.

Vertical scaling has a ceiling — eventually, no single machine is big enough, and the biggest machines are extremely expensive. Horizontal scaling has no real ceiling — you can, in theory, keep adding machines forever. This is why almost every large‑scale system eventually shards its data.

2.2 What goes wrong: the hot partition

The library from the analogy above split books by author’s last name. That sounds fair — 26 letters split across 10 rooms should be roughly even, right? Not quite. In the real world, many more authors have last names starting with “S” (Smith, Singh, Sharma, Stewart…) than with “X” or “Q.” So the room holding S‑authors gets crushed with visitors while the Q‑room librarian reads a newspaper all day.

This is precisely what happens in software systems. If you shard your data using a key that isn’t evenly distributed in the real world — like a user’s country, a product category, or a date — some shards end up holding (or serving) dramatically more data or traffic than others.

2.3 A concrete example

Suppose you build a ride‑hailing app like Uber and you shard your “trips” database by city_id. New York City alone might generate more trips per minute than fifty small towns combined. The New York shard becomes a hot partition — it gets overwhelmed — while dozens of other shards for small towns are nearly empty. You’ve technically “sharded” the database, but you haven’t actually solved your scaling problem, because one machine is still the bottleneck.

Let’s define every term carefully, one at a time, before going further.

3.1 Data skew vs. traffic skew

These are two related but different problems:

Practical implication: When testing a sharded system, feeding it uniformly random test data will almost always hide hot‑partition bugs, because uniform data doesn’t resemble the Zipf‑like skew real users generate. Good load tests deliberately generate skewed traffic to expose these problems before production does.

Let’s look at the pieces that make up a typical sharded system.

Fig 4.1 — A client never talks to shards directly. It talks to a shard router, which consults a shard map (metadata) to know which of the 4 shards owns a given key, then forwards the request there.

4.1 Shard router / coordinator

This is the component that decides which shard should handle a given request. It can be a lightweight library inside your application (client‑side sharding), a dedicated proxy service (like Vitess’s VTGate, or MongoDB’s mongos), or built into the database engine itself (like DynamoDB or Cassandra).

4.2 Shard map / metadata store

A small, highly available store that records which key ranges or hash values map to which physical shard. This is often kept in a separate, strongly consistent store like ZooKeeper, etcd, or a dedicated configuration database, because if this map is wrong, requests go to the wrong place.

4.3 Individual shard servers

Each shard is typically a full database instance (with its own replicas for high availability) holding one slice of the total data.

4.4 Rebalancer / auto‑scaler

A background process that watches load per shard and, when it detects imbalance, splits a hot shard into two, merges cold shards together, or moves data between shards.

4.5 Monitoring & alerting layer

Collects per‑shard metrics (CPU, requests/sec, storage size, latency) so engineers — or automated systems — can detect a hot partition before it causes an outage.

Let’s walk through exactly how a request finds its shard, using the two most common strategies.

5.1 Range‑based partitioning

Data is split by ranges of the shard key. For example, users with IDs 1–1,000,000 go to Shard 1, IDs 1,000,001–2,000,000 go to Shard 2, and so on.

Strength: Range queries (like “give me all orders from January”) are fast because related data sits together.

Weakness: If IDs are assigned sequentially (which they very often are, since most systems use auto‑incrementing IDs or time‑based IDs), all new writes land on the single most recent shard — a classic hot partition, sometimes called “the last shard problem.”

5.2 Hash‑based partitioning

Instead of using the raw key, you run it through a hash function (a function that turns any input into a fixed‑size, well‑scrambled number) and then use that hash to decide the shard. Example: shard = hash(user_id) % number_of_shards.

Strength: Hashing spreads sequential or clustered keys evenly, because a good hash function scrambles similar inputs into very different outputs.

Weakness: Range queries become expensive (you’d need to check every shard), and a single, extremely popular key (like one viral post) is still just one key — hashing spreads different keys evenly, but it cannot split the traffic for one single key across multiple shards on its own.

5.3 Directory‑based partitioning

A lookup table (directory) explicitly maps each key — or each range of keys — to a shard, instead of computing it with a formula. This gives full flexibility (you can move any single key to any shard), at the cost of maintaining and querying that lookup table on every request.

Let’s trace what happens end‑to‑end when a write request enters a sharded system.

Fig 6.1 — Lifecycle of a single write: the shard key is hashed or matched against a range, the shard map resolves it to a physical shard, the write lands there and is replicated, and metrics are emitted so the system can detect if this shard is becoming hot.

6.1 Step‑by‑step

1. Request arrives with a shard key (e.g., user_id=48213).
2. Routing logic computes hash(48213) % 8, or looks up the key in a range table.
3. Shard map lookup confirms which physical server currently owns that hash bucket or range.
4. The write lands on the target shard’s primary node.
5. Replication copies the write to that shard’s replica nodes for durability and read scaling.
6. Metrics are emitted — requests/sec, latency, storage size — tagged per shard, feeding dashboards and alerts.
7. Over time, if metrics show one shard consistently far above the average, a rebalancing or splitting process is triggered (manually or automatically).

This is the heart of the guide. Below are the proven, production‑grade techniques, roughly ordered from “choose this up front” to “apply this once you detect a problem.”

7.1 Choose a high‑cardinality, evenly‑distributed shard key

What it means: “Cardinality” is just a fancy word for “how many distinct values a field can have.” A field like country has low cardinality (maybe 195 possible values, and a few of them — like the US, India, China — dominate). A field like user_id or a random UUID has very high cardinality (millions of nearly‑equally‑likely values).

Rule of thumb: Prefer shard keys with many possible values, where no single value naturally attracts a huge share of the traffic.

7.2 Use consistent hashing

As introduced earlier, consistent hashing places both shards and keys onto a conceptual ring (a circle of hash values from 0 to a very large number, wrapping back to 0). Each key is assigned to the next shard found by moving clockwise around the ring from the key’s hash position.

Fig 7.1 — Consistent hashing ring. Each dot is a data key; it belongs to whichever shard node appears next when moving clockwise. Removing shard S3 only affects the small arc of keys between S2 and S3 — not the whole ring.

Virtual nodes (vnodes)

What it is: Instead of placing each physical shard at just one point on the ring, place it at many points (say, 100–300 virtual positions), scattered randomly around the ring.

Why it exists: With only one point per shard, the ring can still end up lumpy — one shard might, by chance, own a much bigger arc than another. Virtual nodes smooth this out statistically: with hundreds of small positions per shard, the law of large numbers ensures each real shard ends up with a nearly equal total share of the ring, and when a new shard is added, load is pulled evenly from every existing shard instead of just one neighbor.

This technique is used inside Amazon DynamoDB, Apache Cassandra, and Riak.

7.3 Salting hot keys

When one single key (not a range of keys, but one specific key, like one viral post or one celebrity user) is simply too hot for any single shard to handle, hashing alone cannot help — hashing spreads different keys apart, but a specific key always hashes to the same place.

The fix: Attach a small random or rotating “salt” to the key before hashing, effectively turning 1 hot key into N sub‑keys spread across N shards.

// Instead of writing directly to key "post:987654" (hot key),
// spread writes across N logical sub-partitions.
int SALT_BUCKETS = 10;

String buildSaltedKey(String baseKey) {
    int salt = ThreadLocalRandom.current().nextInt(SALT_BUCKETS);
    return baseKey + "#" + salt;   // e.g. "post:987654#7"
}

// Write path
void recordLike(String postId) {
    String saltedKey = buildSaltedKey("post:" + postId);
    shardClient.increment(saltedKey, 1);
}

// Read path: sum all salt buckets to get the true total
long getLikeCount(String postId) {
    long total = 0;
    for (int s = 0; s < SALT_BUCKETS; s++) {
        total += shardClient.get("post:" + postId + "#" + s);
    }
    return total;
}

The trade‑off: reads now need to fan out to all N salted sub‑keys and sum the results, which is more work per read. This is usually a very good trade because writes for a viral hot key vastly outnumber reads of the aggregate count, and the read‑side aggregation can also be cached.

7.4 Composite shard keys

Instead of sharding purely by one field, combine two fields so that the combination spreads more evenly than either alone. Example: instead of sharding purely by celebrity_id (which creates one giant partition per celebrity), shard by (celebrity_id, follower_id_bucket), splitting one celebrity’s followers across multiple shards.

7.5 Time‑based key randomization

If your natural key includes a timestamp (very common — e.g., event_id = timestamp + sequence), all “now” traffic piles onto the newest shard. Fix this by reversing or hashing the timestamp portion, or by prefixing it with a random shard bucket, so writes for “right now” don’t all cluster together.

7.6 Bounded‑load consistent hashing

An enhancement to plain consistent hashing (used internally by systems like Google’s Maglev and some modern load balancers) that caps how much load any single shard can absorb before overflow keys are redirected to the next shard on the ring, guaranteeing a hard upper bound on imbalance rather than just a statistical one.

7.7 Dynamic/adaptive rebalancing (auto‑splitting)

Modern distributed databases (CockroachDB, MongoDB, HBase, Google Bigtable, DynamoDB’s adaptive capacity) monitor per‑shard load continuously and automatically split a shard that’s growing too hot into two smaller shards, then move one half onto a different server. This turns hot‑partition handling from a one‑time design decision into an ongoing, automatic process.

Fig 7.2 — Automatic shard splitting: an overloaded shard is split into two halves by key range; one half stays on the original server, the other is relocated to a less busy server, halving the load on each.

7.8 Caching in front of hot shards

Placing a fast in‑memory cache (like Redis or Memcached) in front of the database absorbs repeated reads for the same hot keys, so the underlying shard only needs to serve occasional cache‑miss traffic instead of every single request.

7.9 Read replicas for hot shards

For read‑heavy hot partitions, adding extra read replicas specifically for that shard (while keeping a single writer) lets you scale read capacity independently, spreading read load across several machines that all serve the same hot data.

7.10 Application‑level request coalescing / rate limiting

Sometimes the fix isn’t purely a database technique — it’s protecting the hot shard by batching many small write requests into fewer, larger ones (coalescing), or by rate‑limiting abusive or accidental traffic spikes before they even reach the shard.

7.11 A minimal consistent‑hashing implementation

It helps to see the ring described in Fig 7.1 as actual, working code. The example below implements a small consistent‑hashing ring with virtual nodes, similar in spirit to what Cassandra and DynamoDB do internally.

import java.util.SortedMap;
import java.util.TreeMap;

class ConsistentHashRing {

    private final SortedMap<Long, String> ring = new TreeMap<>();
    private final int virtualNodesPerShard;

    ConsistentHashRing(int virtualNodesPerShard) {
        this.virtualNodesPerShard = virtualNodesPerShard;
    }

    void addShard(String shardId) {
        for (int i = 0; i < virtualNodesPerShard; i++) {
            long hash = hash(shardId + "#vn" + i);
            ring.put(hash, shardId);
        }
    }

    void removeShard(String shardId) {
        for (int i = 0; i < virtualNodesPerShard; i++) {
            ring.remove(hash(shardId + "#vn" + i));
        }
    }

    String getShardFor(String key) {
        if (ring.isEmpty()) throw new IllegalStateException("No shards registered");
        long hash = hash(key);
        // Find the first virtual node at or after this hash; wrap around if needed.
        SortedMap<Long, String> tail = ring.tailMap(hash);
        long targetKey = tail.isEmpty() ? ring.firstKey() : tail.firstKey();
        return ring.get(targetKey);
    }

    private long hash(String input) {
        // A real implementation should use a well-distributed hash (e.g. MurmurHash3).
        return Math.abs((long) input.hashCode());
    }
}

// Usage
ConsistentHashRing ring = new ConsistentHashRing(200); // 200 vnodes per shard
ring.addShard("shard-1");
ring.addShard("shard-2");
ring.addShard("shard-3");

String owningShard = ring.getShardFor("user:48213");
System.out.println("user:48213 belongs to " + owningShard);

// Adding a new shard only pulls a fair share of keys from existing shards,
// instead of reshuffling everything (unlike plain hash % N).
ring.addShard("shard-4");

Notice that getShardFor never depends on the total number of shards directly — it only walks the sorted ring. That’s exactly why adding or removing a shard doesn’t force a full reshuffle: only the keys that fall in the specific arc near the changed shard move.

7.12 Geo‑partitioning and locality‑aware sharding

For globally distributed applications, an additional dimension matters alongside load: physical distance. Splitting shards by geographic region (e.g., one set of shards for North America, another for Europe, another for Asia) keeps data close to the users who access it most, reducing network latency — but naive geo‑partitioning by country or continent reintroduces the exact low‑cardinality problem described in section 7.1, since population and internet usage are not evenly spread across regions.

The production‑grade fix combines both ideas: partition first by a fine‑grained geographic cell (a small area, not a whole country), then apply consistent hashing within each region so that even a very dense city is spread across multiple shards rather than concentrated in one, while still keeping most reads and writes physically close to the user generating them.

Every fix has a cost. The skill is choosing the minimum complexity your real traffic actually demands.

8.1 Advantages of solving hot partitions well

• Predictable, low‑latency performance for all users, not just some.
• Efficient use of hardware — you pay for capacity you actually use, instead of over‑provisioning every shard to survive worst‑case skew.
• Easier capacity planning, since load per shard is roughly uniform and predictable.
• Higher fault tolerance — no single shard is a disproportionately dangerous single point of failure.

8.2 Disadvantages and costs of the techniques

• Salting increases read complexity (fan‑out reads) and slightly increases storage overhead.
• Consistent hashing with virtual nodes adds implementation complexity and a small memory/CPU cost for ring management.
• Auto‑rebalancing consumes network and CPU resources while data moves, and can itself briefly increase latency during the move.
• Composite keys can make certain queries (e.g., “get everything for this celebrity in one place”) slower, since data is now spread across more shards.

8.3 The core trade‑off

Every technique to fix hot partitions trades some simplicity or query efficiency for better load distribution. There’s no free lunch — the engineering skill lies in choosing the minimum complexity needed for your actual traffic pattern, not applying every technique everywhere.

Why sharding stops scaling the moment one shard becomes the bottleneck.

To reason about performance, it helps to define a simple mental model: if you have N shards and total traffic T, perfectly even distribution gives each shard T / N load. A hot partition means one shard actually handles far more than T / N — sometimes close to the entire T — which means adding more shards stopped helping the moment that one shard became the bottleneck.

This is why measuring the skew ratio (busiest shard’s load ÷ average shard’s load) is one of the most useful health metrics in a sharded system. A skew ratio close to 1.0 means load is well balanced; a skew ratio of 8.0 means your busiest shard is doing the work of eight average shards, and adding more idle shards won’t fix your latency problem at all.

Scalability in a well‑designed sharded system should be close to linear: doubling the number of shards should roughly double total capacity. Hot partitions break this linearity — you can double your shard count and see almost no improvement in your slowest requests, because the bottleneck was never total capacity; it was distribution.

9.1 Why queues form on a hot shard (a queuing theory intuition)

A useful, beginner‑friendly way to understand why hot shards get so slow, so fast, comes from queuing theory. Picture a single checkout counter at a grocery store. As long as customers arrive slower than the cashier can serve them, the line stays short. But as arrivals get close to the cashier’s maximum serving speed, the queue doesn’t grow gently — it grows explosively, because each new customer has to wait for everyone ahead of them, and small random bursts in arrival timing compound.

This is why a hot shard’s latency graph often looks deceptively fine right up until it suddenly spikes: the shard was creeping toward its maximum serving capacity, and once traffic touched that ceiling, wait times exploded non‑linearly rather than increasing gradually. This is also why the skew‑ratio alerting described in the Monitoring section is set at a threshold well below 100% utilization (like 2x average load) — waiting until a shard is visibly struggling is often too late.

9.2 Vertical headroom vs. horizontal headroom

Two different kinds of “room to grow” matter for a sharded system. Vertical headroom is how much more load one existing shard’s machine can absorb before it saturates. Horizontal headroom is how much more total capacity exists across all shards combined. A system can have enormous horizontal headroom (dozens of nearly‑idle shards) while having zero vertical headroom on the one hot shard that actually matters to a struggling user — which is precisely the situation a hot partition creates, and precisely why “we have plenty of capacity” dashboards can be dangerously misleading if they only show system‑wide totals.

A hot partition is a reliability risk, not just a performance one.

If one shard’s server runs out of memory, hits its maximum connection limit, or crashes under load, every user whose data lives on that shard experiences an outage — even though the other 95% of your infrastructure is perfectly healthy.

• Replica sets per shard — each shard should have its own primary and at least 2 replicas, so a single hardware failure on the hot shard doesn’t cause data loss.
• Circuit breakers — application code should detect when a specific shard is timing out and temporarily stop sending it more traffic (fail fast) instead of piling on retries that make the hot shard even hotter.
• Bulkheading — isolate resources (thread pools, connection pools) per shard so that one overloaded shard’s slowness cannot exhaust connections meant for other, healthy shards.
• Graceful degradation — for non‑critical reads against a struggling hot shard, serve slightly stale cached data rather than blocking the user entirely.

Hot partitions have a security angle too — and skipping this is how a small oversight becomes a targeted denial‑of‑service vector.

An attacker who understands your shard key logic could deliberately craft requests that all hash to the same shard, effectively launching a denial‑of‑service attack using far less traffic than a typical DDoS would require, because they’re concentrating damage on one weak point instead of spreading it thin.

• Don’t expose your sharding logic in client‑visible identifiers or error messages — this makes deliberate targeting harder.
• Rate‑limit per shard key, not just per client IP, so a single abusive account or bot cluster can’t monopolize one shard’s capacity.
• Use unpredictable hash seeds (a secret “salt” added to your hash function) so external actors cannot precompute which inputs will collide onto the same shard.
• Monitor for anomalous per‑shard traffic spikes as a security signal, not just a performance one — a sudden, targeted spike on one shard can indicate an attack rather than organic popularity.

You cannot fix what you cannot see — and averages are exactly what hide a hot partition.

Effective hot‑partition monitoring tracks metrics per shard, not just system‑wide averages, because averages hide exactly the imbalance you’re trying to catch.

12.1 Key metrics to track per shard

• Requests per second (reads and writes separately)
• p50 / p95 / p99 latency — the 99th percentile is especially important, since a hot shard often shows normal average latency but terrible tail latency
• CPU and memory utilization of the shard’s host machine
• Storage size (data skew, separate from traffic skew)
• Connection pool saturation
• Error rate / timeout rate

12.2 The skew ratio dashboard

A single, powerful chart to build: max(shard load) ÷ avg(shard load), tracked over time. When this ratio crosses a threshold (commonly 2x–3x), it should trigger an alert for engineers to investigate — well before the hot shard actually fails.

double computeSkewRatio(Map<String, Long> requestsPerShard) {
    long total = requestsPerShard.values().stream()
                     .mapToLong(Long::longValue).sum();
    long max = requestsPerShard.values().stream()
                     .mapToLong(Long::longValue).max().orElse(0);
    double average = (double) total / requestsPerShard.size();

    if (average == 0) return 1.0;
    return max / average;
}

// Usage
double skew = computeSkewRatio(shardTrafficMap);
if (skew > 2.5) {
    alerting.fire("HOT_PARTITION_DETECTED", skew);
}

12.3 Distributed tracing

Tools like OpenTelemetry, Jaeger, or Zipkin let you tag each trace with the shard it touched, so when a specific request is slow, you can immediately see “this request was slow because it hit Shard 7, and Shard 7 has been overloaded for the last 10 minutes” — turning a mysterious slowdown into an obvious, actionable finding.

You almost never build sharding from scratch anymore — you inherit it from a managed service and design around its knobs.

Most teams today don’t build sharding infrastructure from scratch — they lean on managed cloud services that have hot‑partition mitigation built in:

• Amazon DynamoDB — automatically partitions tables and includes adaptive capacity to absorb temporary hot keys; still recommends high‑cardinality partition keys as the first line of defense.
• Google Cloud Bigtable / Spanner — automatically splits and merges ranges based on load and size, and Spanner adds distributed transactions on top of automatic sharding.
• MongoDB (sharded clusters) — supports both range‑based and hashed shard keys, plus “zone sharding” for geographic data distribution, and has built‑in chunk‑splitting and balancing.
• Vitess (used by YouTube, Slack, GitHub) — adds transparent sharding on top of MySQL, including resharding with minimal downtime.
• CockroachDB / YugabyteDB — automatically split ranges as they grow and rebalance them across nodes, inspired by Google Spanner’s design.

Even with these managed features, the shard/partition key you choose at table‑design time remains the single biggest lever you control — cloud auto‑balancing helps absorb surprises, but it works far better when the underlying key design is already reasonable.

How the same problem shows up differently across every layer of your data stack.

14.1 How this plays out differently across database types

14.2 Caching layers

A cache like Redis in front of your shards absorbs read traffic for hot keys almost entirely, since a well‑tuned cache can serve millions of reads per second for popular items from memory, leaving the underlying shard to handle only cache misses and writes.

14.3 Load balancing considerations

Load balancers sitting in front of your shard router should ideally be “shard‑aware” — capable of routing based on shard health, not just round‑robin — so that if one shard’s servers are struggling, the load balancer can shed or slow traffic to that specific path without affecting requests bound for healthy shards.

Patterns to reach for, anti‑patterns to avoid even when they “look reasonable.”

15.1 Recommended patterns

15.2 Anti‑patterns to avoid

A practical checklist distilled from the sections above.

16.1 Best practices checklist

• Analyze your real (or realistically projected) traffic distribution before choosing a shard key — don’t guess.
• Prefer high‑cardinality keys; avoid low‑cardinality fields as the sole shard key.
• Use consistent hashing with virtual nodes for any system expected to grow or shrink its shard count over time.
• Build per‑shard monitoring and a skew‑ratio alert from day one, not after the first incident.
• Design your read/write paths so salting can be added later without a full rewrite (e.g., abstract shard‑key construction behind one function).
• Test with realistic, skewed synthetic data (a Zipfian/power‑law distribution) rather than uniform random test data, which hides hot‑key problems until production.
• Plan a rebalancing strategy up front — know how your system will split or move a shard before you actually need to do it under pressure.

16.2 Common mistakes

• Assuming “we sharded the database” automatically means “load is now balanced” — sharding only helps if the key spreads load evenly.
• Testing only with small, evenly distributed sample data, which hides skew until real users arrive.
• Reacting to a hot partition only after an outage, instead of monitoring the skew ratio proactively.
• Adding more shards without fixing the underlying key design — this rarely helps if one key is still concentrating all the traffic.
• Forgetting that hot partitions can appear gradually (a slowly‑growing power user) as well as suddenly (a viral event) — monitoring needs to catch both patterns.

The same patterns, at the scale where they were forged.