Tutorials System Design Tutorial
Database Sharding Strategies — Complete Guide
Database Sharding Strategies — Complete Guide: free step-by-step lesson with examples, common mistakes, and interview tips — part of System Design Tutorial on Toolliyo Academy.
On this page
System Design Tutorial · Lesson 23 of 100
Database Sharding Strategies
Basics → Scale → Interview
Basics · 1 — Building blocks · ~6 min · Module 3: Database Systems
What is this?
Sharding splits data across multiple databases by a key (userId, tenantId, orderId range) so one primary is not the ceiling.
Why should you care?
When ShopNest orders no longer fit comfortably on one primary, shards buy capacity — with query complexity as the price.
See it live — copy this example
Sketch the architecture on paper. These lessons focus on concepts and trade-offs.
shardKey = userId % 4
shard0..shard3 each hold a slice of orders
Good: queries that include userId
Pain: “all orders yesterday” needs scatter-gatherRun Example »
This lesson uses terminal or setup steps. Run commands on your computer — the live editor appears on coding lessons.
What happened?
- A good shard key keeps related rows together and avoids hot spots.
- Cross-shard queries and transactions become hard — design APIs accordingly.
Practice next
- Propose userId as ShopNest order shard key.
- List queries that still work single-shard.
- List queries that become fan-out.
- Compare hash vs range sharding for userId.
- Design resharding as a future project, not an afterthought.
Remember
Shard by a high-cardinality key. Keep transactions single-shard. Accept fan-out for rare global queries.
User-sharded orders
ShopNest routes order writes by userId hash.
Outcome: Primaries stay within size SLOs as GMV grows.
Interview prep for this lesson
Practice these questions aloud after reading—each links to a full structured answer.
Sign in to ask a question or upvote helpful answers.
No questions yet — be the first to ask!
