System Design interview questions: Sharding

Sharding splits one dataset across multiple database instances, with a shard key determining where each row lives. Hashing that shard key spreads writes more evenly than a steadily increasing key under range partitioning, which sends new writes to a single shard. Hash placement scatters consecutive keys, so range scans and cross-shard joins become more expensive.

In a range-sharded system, a single-key read is handled by first extracting the key, then looking up the owning range in the shard map, forwarding the request to that shard, having the shard execute the read locally, and finally returning the result to the client. Each step depends on the output of the previous one, so the order is fixed.

A events table is range-sharded by its created_at timestamp, so each shard owns a contiguous time window. Every new insert carries the current timestamp, so all new writes land on the one shard that owns the most recent window. This creates a write hotspot on that shard while the older shards sit mostly idle. Switching the shard key to a hash of a high-cardinality column spreads these writes across all shards, at the cost of efficient range scans over created_at.

Shard on a high-cardinality key, such as a hash of the tenant or entity id, so writes spread evenly across partitions. A monotonic timestamp routes every current write to whichever shard owns the latest range, creating a hot partition no matter how many shards exist. Adding replicas or vertically scaling the busy shard only raises one box's ceiling; neither balances the write distribution.

Use Snowflake-style ids that pack a timestamp, a node id, and a per-node sequence counter — coordination-free, unique, and naturally time-ordered. Every node mints ids locally with no round-trip, and the timestamp prefix gives the index locality you want. A central sequence reintroduces the coordination and single point of failure; UUIDv4 is coordination-free but fully random, so it scatters B-tree inserts; and hashing row contents lets identical rows collide.

The approaches that genuinely help are splitting the hot key range into smaller sub-ranges and migrating some while double-writing during cutover, using consistent hashing with virtual nodes so adding capacity remaps only a fraction of keys, and introducing a finer-grained or composite shard key so the concentrated key spreads across partitions. Taking the shard offline to dump and restore is downtime, and vertically scaling only the hot node never rebalances anything.

A good shard key has high cardinality and a roughly uniform access distribution so reads and writes spread evenly across shards, and it ideally matches your most common query so requests hit a single shard instead of scattering. A bad shard key creates a hotspot: a low-cardinality or monotonically increasing key (like an auto-increment id or a timestamp) sends most traffic to one shard, producing uneven load and a hot partition while others sit idle. It also forces expensive scatter-gather queries and painful resharding when one shard outgrows its capacity.

Requirements. Two operations dominate: create (write a mapping, optionally with a custom alias and expiry) and redirect (look up a code and 30x to the long URL). The system is overwhelmingly read-heavy (100:1), so the redirect path is what we optimise. I'd confirm: are custom aliases required (yes), do links expire (optional TTL), and how precise must click counts be (approximate/eventually-consistent is fine). I'd use a 302 (temporary) redirect so we keep serving redirects through our system and can still count clicks; a 301 would let browsers cache and bypass us.

Capacity. ~40 writes/sec average, ~200/sec peak; ~4K reads/sec average, ~20K peak. Storage: ~6B links over 5 years; at ~500 bytes/row (code, URL, metadata) that's ~3 TB — comfortably shardable. Keyspace: base62 with 7 characters gives 62⁷ ≈ 3.5×10¹² codes, far more than 6B, so 7 chars (often padded to a fixed length) is plenty. The hot working set (recently/ popularly accessed links) is a small fraction of 6B, so a cache of tens of GB covers the bulk of redirect traffic.

Data model. A single mapping table/collection keyed by the short code: code (PK) → long_url, created_at, expires_at, owner_id. Point lookups by primary key suit a key-value store (DynamoDB/Redis-backed) or a sharded relational table sharded by code. Click counts live separately — incrementing a counter on every redirect would put write load on the read path — so clicks are emitted as events and aggregated asynchronously.

Short-code generation. Generate a unique 64-bit id (a distributed counter handed out in ranges per server, or a Snowflake-style id) and base62-encode it to get the short code; this guarantees uniqueness with no collision checks and no hotspot from a single shared counter. Custom aliases are written directly with a uniqueness check and stored in the same table, reserving that code. (A hash-of-URL scheme is the alternative but needs collision handling and breaks idempotency for duplicate URLs.)

Read/write paths. Write: allocate id → base62 → insert mapping → return the short URL. Redirect: a load balancer / CDN fronts stateless app servers; the server does a cache-aside lookup (code → long_url) in Redis, falling back to the store on a miss and populating the cache, then returns a 302. This keeps p99 well under 100 ms for cache hits. Expiry is enforced by TTL on both the row and the cache entry. Each redirect fires a lightweight click event onto a queue (Kafka) that a consumer aggregates into per-link counts.

Bottleneck & scaling. The bottleneck is the redirect read path at peak. We scale it with cache layers (most reads never touch the store), read replicas, and sharding the mapping store by code so lookups stay single-shard. Id generation scales by handing each server an independent id range (or using Snowflake), avoiding a single global counter as a SPOF. At 10× traffic, the cache absorbs most of it; we add cache nodes and replicas and, if needed, push redirects further to the edge.

False. Monotonically increasing keys concentrate all writes on the last shard — the one owning the current maximum range — the classic hotspot-shard problem, while other shards sit idle for writes. Even though such keys are high-cardinality, they are temporally correlated. Even write distribution needs a hash-based or consistent-hash key, or random keys like UUIDv4; timestamp-ordered ULIDs recreate the same hotspot.

Naive sharding with hash(key) % N remaps almost every key when N changes, forcing a massive reshuffle whenever you add or remove a node. Consistent hashing places nodes and keys on a hash ring so that adding/removing a node only moves the keys in one adjacent arc — roughly 1/N of the data — rather than nearly all of it. Virtual nodes (many ring positions per physical node) smooth out the uneven key distribution and let you weight heterogeneous machines, avoiding hot shards.