NexisyTech Learningby Nexisy Technologies

Sharding Strategies

Range, hash, consistent hashing and directory-based sharding — how data is split across servers.

Advanced10 min read3 interview questions

Sharding splits one logical dataset across several databases (shards). Each shard holds a subset of rows, so writes and storage scale with the number of shards.

The shard key is the most important decision. A good key spreads load evenly and keeps the data a query needs on one shard.

Diagram

ApplicationShard routerhash(user_id) % 3Shard 0users with hash 0Shard 1users with hash 1Shard 2users with hash 2
A router maps each shard key to exactly one shard.

Key concepts

Range sharding
Rows split by key ranges (A–F, G–M…) or dates. Range queries are easy, but hot spots form when new keys cluster.
Hash sharding
hash(key) % N spreads rows evenly. Range queries need every shard, and changing N moves most rows.
Consistent hashing
Keys and shards sit on a ring; adding a shard moves only about 1/N of keys. Used by Cassandra and DynamoDB.
Directory sharding
A lookup table maps each key (or tenant) to a shard. Flexible and movable, but the directory must be fast and available.
Hot shard
One shard receiving far more traffic than others, e.g. a celebrity account or a huge tenant.

Trade-offs

Benefits

  • Write throughput and storage scale horizontally
  • Smaller indexes per shard
  • Failures affect only part of the data

Costs

  • Cross-shard joins and transactions are hard
  • Resharding is a major operation
  • More databases to back up, patch and monitor

Use it when

  • A single primary can no longer handle writes or storage
  • Multi-tenant SaaS where tenants map naturally to shards

Common mistakes

  • A shard key like created_date that sends all new writes to one shard
  • Queries that must fan out to every shard on the hot path
  • Auto-increment IDs that collide across shards — use UUIDs or a central ID service

Interview questions

Q1Why is hash(key) % N painful when you add a shard?
Changing N changes the result for most keys, so most data must move. Consistent hashing or many virtual shards mapped to physical servers avoid this.
Q2How would you shard a multi-tenant SaaS database?
By tenant ID, usually with a directory so large tenants can get a dedicated shard and small tenants share one. Every query already filters by tenant, so it stays on one shard.
Q3How do you handle a query that needs data from all shards?
Scatter-gather: send it to every shard in parallel and merge results. For frequent analytics, replicate data into a separate warehouse instead.

Related lessons

Data & Storage

Database Scaling & Replication

From one database server to replicas, partitions and shards — in the order you should reach for them.

Intermediate10 min read Data & Storage

CAP Theorem & Consistency

During a network partition, a distributed store must choose between consistency and availability.

Intermediate8 min read Data & Storage

SQL vs NoSQL

Relational, document, key-value, wide-column and graph databases — match the store to the access pattern.

Beginner8 min read