Art of Codeartofcode
Lesson 7 of 15

15. Sharding

1
The picture to keep in your head
2
15.1 Why shard at all?
3
15.2 How do you choose the shard key?
4
15.3 What are the ways to map keys to shards?
5
15.4 What is a hot shard?
6
15.5 How do you add shards without moving everything?
7
15.6 What happens to queries and joins that cross shards?
8
15.7 How do you keep IDs and unique rules across shards?
9
15.8 How do sharding and replication work together?
10
Memory card and where the analogy breaks
11
Practice: five levels
12
Interview questions
13
Solutions
14
Sources
15
Code lab
15. Sharding

15.6 What happens to queries and joins that cross shards?

3 min read+10 XP

At the exam centre: "Show me roll number 4,512's answer sheet" means going to one hall. "Who scored highest overall?" means visiting every hall, collecting each hall's top scorer, and comparing. Slower, and if one hall is late, everyone waits.

In the system:

a query with the shard key hits one shard; a query without it hits every shard and merges.

Figure: choose the shard key from your frequent queries; send the rest to a copy built for them.

  • Single-shard queries include the shard key: "orders for user 7" goes to one shard. Fast and cheap.
  • Scatter-gather queries don't: "all orders over ₹2,000 today" must ask every shard and merge the results. Cost grows with the number of shards, and the query is as slow as the slowest shard (Chapter 5's fan-out: with 16 shards each slow 1% of the time, about 15% of such queries are slow).
  • Joins across shards (orders on one shard, the book's details on another) can't be done inside one database. Options:
    • Co-locate related data under the same shard key (a user's orders, items and payments together).
    • Replicate small reference tables (books, categories) to every shard, so joins with them stay local.
    • Denormalise: store the book title inside the order (Chapter 8).
    • Join in the application: fetch from each place and combine.
  • Global secondary indexes: to look up orders by book_id quickly, keep a separate index (itself sharded by book_id) mapping book → order IDs, updated alongside writes or from change events.
  • Analytics: stream all shards' changes into a separate analytics store built for scanning (Chapter 22). Don't run company reports as scatter-gather on the live shards.

Memory code: "One hall for one student; every hall for the topper, so keep topper questions rare."