Sharding Strategies

What it is

Sharding is the practice of horizontally partitioning a dataset across multiple independent database nodes (shards), each owning a mutually exclusive subset of the data. Each shard is a fully functional database instance that handles reads and writes for its portion. A shard router or client-side logic determines which shard a given request should be directed to based on a shard key extracted from the data or query.

Unlike replication (where all nodes hold the same data), sharding means each node holds different data. This allows both storage and write throughput to scale horizontally. MongoDB, Vitess (for MySQL), CockroachDB, Cassandra, and DynamoDB all implement sharding as a first-class concern. At its core, sharding trades query simplicity for unlimited horizontal scalability: single-key lookups become fast and isolated, while cross-shard queries become expensive or impossible.

Why it exists

Relational databases and single-node key-value stores eventually hit hard limits: a PostgreSQL instance can realistically handle around 10,000–20,000 transactions per second and store up to a few terabytes before write throughput or storage becomes the bottleneck. Vertical scaling can extend this window, but there is a practical ceiling. Sharding breaks through that ceiling by distributing data such that each shard handles only a fraction of the total write load and stores only a fraction of the total data, and the aggregate capacity of the cluster grows linearly with the number of shards.

The problem became acute for the internet's largest applications. Facebook's user table, Twitter's tweet storage, and Amazon's order database all grew beyond what any single machine could hold. Sharding, combined with consistent hashing and eventually consistent replication within each shard, is what makes billion-record databases with millions of writes per second possible.

When to use

• A single database node has become the write bottleneck and vertical scaling has been exhausted or is cost-prohibitive.
• The dataset size exceeds the practical storage or memory capacity of a single machine.
• Your query patterns are largely single-entity lookups (e.g., get user by userId) that naturally align with a shard key.
• You require geographic data partitioning — routing user data to region-specific shards for compliance or latency.
• The data model is fundamentally multi-tenant and each tenant's data is logically isolated, making tenant-based sharding natural.
• You are using a database that supports sharding natively (MongoDB, Cassandra, DynamoDB) and the operational complexity is managed by the platform.

When not to use

• Your query patterns frequently require cross-shard joins or aggregations — these become scatter-gather operations with high latency and coordination cost.
• The data access pattern is highly uneven and you cannot identify a shard key that distributes load evenly, risking hot shards.
• Your data model relies heavily on ACID transactions spanning multiple entities that would reside on different shards.
• The complexity of resharding, cross-shard query routing, and shard topology management outweighs the scalability benefit for your current scale.

Typical architecture

  Application Layer
        │
        ▼
  ┌─────────────────────┐
  │    Shard Router      │  (Vitess VTGate / Mongos / app-side)
  │  shard = hash(key)  │
  └──────┬──────┬───────┘
         │      │        └── ...
         ▼      ▼              ▼
  ┌────────┐ ┌────────┐  ┌────────┐
  │Shard 0 │ │Shard 1 │  │Shard N │
  │Primary │ │Primary │  │Primary │
  │+Replica│ │+Replica│  │+Replica│
  └────────┘ └────────┘  └────────┘

  Consistent Hashing Ring (3 shards):
       0
      / \
   Shard2  Shard0
    /         \
  240         120
    \         /
   Shard1----
      180

  Range Sharding (user_id):
  ┌──────────────────────────────┐
  │ Shard 0: user_id 0–9,999,999 │
  │ Shard 1: 10M–19,999,999      │
  │ Shard 2: 20M–29,999,999      │
  └──────────────────────────────┘

  Hash Sharding:
  shard = MD5(user_id) % num_shards
  user_id=42 → shard 2
  user_id=99 → shard 0
          

Pros and cons

Implementation notes

Shard key selection is the most critical decision. A good shard key has high cardinality (many distinct values), uniform distribution (no hot spots), and alignment with the most common query access pattern (single-shard lookups). User ID is a classic choice for user-centric applications. Timestamp is a poor shard key because all current writes go to a single "latest" shard. Composite keys (e.g., tenant_id + entity_id) work well for multi-tenant systems. Avoid choosing a shard key that requires frequent range queries across shard boundaries.

Consistent hashing is preferred over modulo hashing because it minimizes data movement when shards are added or removed. With modulo hashing, doubling from 4 to 8 shards remaps 75% of keys. With consistent hashing, adding one node remaps only 1/N of keys. Virtual nodes (vnodes) in Cassandra and DynamoDB's partition ring implement this pattern. When resharding is needed, use a two-phase approach: first double-write to both old and new shards, then backfill historical data, then cut over reads. This avoids any downtime but requires temporary coordination logic.

Common failure modes

• Hot shard: A disproportionate share of traffic routes to one shard because the shard key is correlated with activity (e.g., celebrity users, trending topics). Mitigate with key salting or choosing a more uniform key.
• Cross-shard query explosion: A developer writes a query without a shard key filter; it fans out to all N shards simultaneously, multiplying database load by N. Enforce shard-key presence in query review gates.
• Resharding data loss: Incomplete data migration during resharding leaves some keys unreachable in both old and new shards. Always verify row counts before cutting over.
• Shard configuration drift: Different shards run different schema versions because migrations were applied inconsistently. Use idempotent, backward-compatible migrations applied to all shards atomically.
• Router single point of failure: A centralized shard router (Mongos, VTGate) that fails takes down all database access. Deploy multiple router instances with a load balancer.

Decision checklist

• A shard key has been identified with high cardinality, uniform distribution, and alignment with the primary query pattern.
• Cross-shard query patterns have been enumerated and their performance implications accepted or mitigated.
• The sharding strategy (range, hash, directory, consistent hashing) has been chosen based on access patterns and resharding requirements.
• A resharding procedure is documented and tested, including a rollback plan.
• The shard router or routing logic has been made highly available with no single point of failure.
• Distributed transaction requirements have been assessed; cross-shard ACID transactions should be minimized or eliminated by design.

Example use cases

• Social network messages: A messaging platform shards its messages table by conversation_id, ensuring all messages for a conversation reside on a single shard and timeline queries remain fast.
• Multi-tenant SaaS: A B2B platform shards by tenant_id, providing strong isolation between customers and enabling per-tenant scaling by moving large tenants to their own dedicated shards.
• IoT time-series: A sensor data platform shards by device_id using consistent hashing, ensuring device-specific queries never cross shards while supporting millions of devices across hundreds of shards.

Related patterns

• Partitioning Patterns — table-level partitioning within a single database node, often a precursor to sharding.
• Hot Partition Mitigation — strategies for redistributing load when a shard key creates uneven distribution.
• Consistent Hashing — the algorithm underpinning most modern shard key routing.
• Read Replicas — combined with sharding, replicas within each shard handle read scale independently.

Further reading

• MongoDB Sharding Documentation
• Vitess Sharding Reference (MySQL)
• Amazon Dynamo Paper — Consistent Hashing and Partitioning (SOSP 2007)