> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Sharding Actually Is

> Explains database sharding by splitting rows across machines, shard selection methods, routing strategies, trade-offs, and operational challenges for horizontal scaling and re-sharding.

Sharding is the practice of splitting your rows across multiple machines so that no single server stores the entire dataset. This approach—also called horizontal scaling—lets you add many ordinary machines instead of upgrading a single, larger machine. Each machine stores a subset of the rows; that subset is called a shard.

A shard is simply one machine (or logical partition) holding a portion of the table rows. All shards typically share the same table schema (same columns and layout). For example, every shard in a social app might have the columns: `user_id`, `username`, and `follower_count`. Leo’s row will exist entirely on one shard, and Chris’s row will exist entirely on another, but both shards use the same schema.

![A schematic diagram of four database shards (Shard 0–3) shown as cylinder icons with tables beneath listing user IDs, usernames and follower counts. Below the tables are highlighted user profile cards (e.g., Leo and Chris) linked to entries in the shards.](https://mintcdn.com/kodekloud-c4ac6d9a/U9fTv2NKZBAqmNMH/images/System-Design-Database-Sharding/Sharding-Fundamentals/What-Sharding-Actually-Is/sharded-db-user-profiles-diagram.jpg?fit=max\&auto=format\&n=U9fTv2NKZBAqmNMH\&q=85\&s=d8656884ef767bd6850e28c480fa1868)

A common simple sharding rule is to use the user ID modulo the number of shards. For example, with four shards:

* Compute `user_id % 4` to get a remainder of `0`, `1`, `2`, or `3`.
* Map that remainder to a shard:
  * `0 → shard 0`
  * `1 → shard 1`
  * `2 → shard 2`
  * `3 → shard 3`

Example calculations:

* `1 % 4 = 1` → shard 1
* `4 % 4 = 0` → shard 0
* `7 % 4 = 3` → shard 3

You can express this logic in simple code:

```js theme={null}
function shardFor(userId, numShards) {
  return userId % numShards;
}

// Example:
shardFor(7, 4); // returns 3 -> shard 3
```

Table: remainder → shard mapping

| Remainder (`user_id % 4`) | Assigned Shard |
| - | - |
| `0` | `shard 0` |
| `1` | `shard 1` |
| `2` | `shard 2` |
| `3` | `shard 3` |

Why teams shard: a single primary database has a finite write throughput. By splitting data across four machines, Chirp effectively has four primaries; each can accept writes for the rows it stores. If write capacity is still insufficient, you can add more shards (e.g., 8, 16, …) and distribute rows across them. This horizontal scaling increases write throughput by distributing load.

Pick a shard key that balances traffic. A good shard key spreads writes and reads evenly; a poor one can create “hot” shards. Consider user ID hashing or composite keys to avoid hotspots.

Splitting data introduces new challenges. One immediate question: when a request arrives that needs Alan’s data, how does the

![A schematic diagram of a mobile client ("Leo") sending a request to an app/server that routes queries to four database shards (Shard 0–3), each showing stored rows. The diagram notes the app "needs Alan's row" and marks each shard as primary.](https://mintcdn.com/kodekloud-c4ac6d9a/U9fTv2NKZBAqmNMH/images/System-Design-Database-Sharding/Sharding-Fundamentals/What-Sharding-Actually-Is/leo-client-needs-alans-row-shards.jpg?fit=max\&auto=format\&n=U9fTv2NKZBAqmNMH\&q=85\&s=e62f66a597dbda925ac5702e3fc0578e)

system know which shard holds Alan’s row? The answer depends on how you partitioned the data. Common strategies include:

| Strategy | How it works | Pros | Cons |
| -: | - | - | - |
| Hash-based (modulus) | Apply a hash or `id % N` to the shard key | Fast, evenly distributes keys (if well-chosen) | Harder to do range queries; re-sharding can be expensive |
| Range-based | Assign contiguous ranges of keys to shards (e.g., IDs 1–1000 → shard A) | Efficient range scans and ordered queries | Can produce hotspots if IDs are skewed |
| Lookup directory | Use a central mapping service or table that maps keys to shards | Flexible—easy to change mapping for individual rows | Single point of failure/latency if not replicated or cached |

Routing decisions can be implemented in different places:

* Application layer: the app computes the shard and directs the query to the correct database.
* Middleware/proxy: a routing service sits between app and databases and forwards requests.
* Lookup service: a small directory service that the app queries to find the shard for a particular key.

Each approach has trade-offs in complexity, latency, and operational cost. Later sections will dig into re-sharding, cross-shard queries, transactions, and patterns for migrating data between shard layouts.

Further reading:

* [Database sharding (Wikipedia)](https://en.wikipedia.org/wiki/Shard_\(database_partitioning\))
* [What is database sharding? (AWS)](https://aws.amazon.com/nosql/what-is-database-sharding/)

> **[Watch Video](https://learn.kodekloud.com/user/courses/database-sharding/module/175adbde-c701-4f76-a3fc-23e90af90acb/lesson/bc602959-290e-4fdd-b25f-5e410df38a90)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.