Database Sharding: What It Is and When to Use It
Fast recall
Quick revision
Core answer
Whether you understand sharding as a last resort rather than a first response to scaling challenges, and whether you can reason about the operational complexity it introduces.
Recommending sharding as the first solution to any scale problem. Caching, read replicas, and query optimization can solve most scale issues with far less complexity.
Discuss shard key selection as the most important and most difficult decision -- a poor shard key creates hotspots or makes cross-shard queries expensive.
Interview-ready guide
Interview answer
Sharding gets mentioned in almost every system design interview, but candidates who suggest it early in a design session are usually skipping past simpler solutions that would do the job — it's a last resort, not a starting point.
What sharding is and why it differs from read replicas
- Sharding splits data horizontally across multiple database servers, each owning a slice of the rows determined by the shard key — which means writes are distributed too, something read replicas can't do since all writes still funnel through one primary
- The routing logic lives in the application or a middleware layer: hash the shard key or check its range, determine which server owns it, and connect there
Shard key — the decision that can't easily be undone
- A good shard key distributes both data volume and write traffic evenly —
user_idis the classic choice because most application queries are scoped to one user, so reads and writes naturally land on one shard without cross-shard coordination - A bad shard key creates hotspots — sharding by
created_atmeans all current writes hit the newest shard while older shards sit idle; sharding bycountryoften gives one shard 40% of users
What sharding breaks
- Cross-shard queries require scatter-gather — the application fans out to every shard, merges results in memory, and handles sorting and pagination itself, which means latency multiplies with the shard count
- Distributed transactions across shards require two-phase commit or application-level saga patterns — there's no database-level multi-shard ACID
Before sharding: add Redis caching for hot reads, add read replicas to distribute SELECT load, tune queries and add missing indexes, vertically scale the primary. Those approaches handle most applications to enormous scale. Sharding is correct when write throughput has genuinely exceeded what a single primary can sustain.
Database Sharding: What It Is and When to Use It
Direct Answer
sharding is the practice of horizontally partitioning data across multiple database instances (shards), each holding a subset of rows. It is used when a single database node cannot handle the volume of data or request throughput -- typically after vertical scaling and read replicas have been exhausted. Sharding trades operational simplicity for horizontal scalability.
Code Example
// Conceptual shard routing in Java
public class ShardRouter {
private static final int SHARD_COUNT = 4;
private final Map<Integer, DataSource> shards;
// Hash-based shard key on userId
public DataSource getShardForUser(long userId) {
int shardId = (int) (userId % SHARD_COUNT);
return shards.get(shardId);
}
// Range-based shard key on created_date
// Shard 0: 2020, Shard 1: 2021, Shard 2: 2022, Shard 3: 2023+
public DataSource getShardForOrder(LocalDate createdDate) {
int year = createdDate.getYear();
int shardId = Math.min(year - 2020, SHARD_COUNT - 1);
return shards.get(shardId);
}
}
// Spring AbstractRoutingDataSource for transparent shard routing
public class ShardingDataSource extends AbstractRoutingDataSource {
@Override
protected Object determineCurrentLookupKey() {
// Set via ThreadLocal before each request
return ShardContext.getCurrentShardId();
}
}
// Anti-pattern: cross-shard join (avoid at all costs)
// SELECT * FROM shard1.orders o JOIN shard2.customers c ON o.customer_id = c.id
// Requires application-level join across multiple network calls
Common Mistakes & Pitfalls
Recommending sharding as the first solution to any scale problem. Caching, read replicas, and query optimization can solve most scale issues with far less complexity.
Check your understanding
Answer these without looking back at the article.
- What is consistent hashing and how does it help with resharding?
- How do you handle a query that needs data from multiple shards?
- What is the difference between sharding and partitioning?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.