Question 1

A chat app stores messages. The main query is "latest 50 messages in conversation X", and group chats have up to 1,000 members. What is the shard key for messages?

Accepted Answer

Conversation id Sharding by conversation id puts every message of a conversation on one shard, so the main query hits one partition, as Discord does with channel plus time bucket. Message id scatters a conversation across all shards. Timestamp makes the newest shard take every write. Sender id splits a group conversation across up to 1,000 shards.

Question 2

A cache cluster places keys with hash(key) mod N on 10 nodes. You add an 11th node. Roughly what fraction of keys move?

Accepted Answer

About 91% A key stays only if hash mod 10 equals hash mod 11, which holds for about 10 in 110 values, so about 91% move and the cache effectively goes cold. About 9% (1/11) is what consistent hashing would move. 50% is a guess with no basis. Mod N placement has no notion of keys staying put.

Question 3

A consistent hash ring has 4 physical nodes. Load is uneven, and when a node fails its whole range lands on a single neighbour. What fixes both?

Accepted Answer

Give each node many virtual nodes on the ring With many virtual nodes per server, each server owns many small ranges, so load evens out and a failed node's ranges spread over all survivors. Replication adds copies but the neighbour still inherits the range. Range partitioning has its own hot spot problems and does not spread failover. A larger hash space does not change how few points the 4 nodes occupy.

Question 4

An orders table is range partitioned on created_at. All writes land on the newest partition and it is saturated. What fixes it?

Accepted Answer

Partition by a hash of order id or customer id A monotonic key concentrates every insert on the latest range. Hashing a high cardinality key spreads writes across all partitions. Read replicas do not take writes. A bigger machine buys time but the hot spot remains. An auto increment id is just as monotonic as a timestamp.

Question 5

A DynamoDB table keyed by user id receives most of its writes on one celebrity's key, throttling that partition. Reads of that user's data can tolerate fanning out. What is the standard fix?

Accepted Answer

Write sharding: append a random suffix 0 to N to the key and read all N on query Per partition throughput is capped, so table capacity does not help a single hot key. Suffixing spreads one logical key over N partitions, and the reader merges N results. A GSI with the same key has the same hot spot. Consistency mode does not change write distribution.

Question 6

A user edits their profile, reloads and sees the old value because reads go to async replicas. Other users may lag a few seconds. What fixes it with the least cost?

Accepted Answer

Route that user's reads to the leader for a short window after they write Read your writes only needs to hold for the writer, so pinning their reads to the leader (or a replica caught up to their write position) for a short window is enough. Synchronous replication fixes it for everyone at a large write latency cost. Retrying until it changes cannot tell an unchanged value from lag. A cache in front adds another stale copy.

Question 7

A leader with asynchronous replication crashes and a follower is promoted. What is the risk?

Accepted Answer

Writes the old leader acknowledged but had not replicated are lost Async replication acknowledges before followers have the write, so failover can drop the tail, and if the old leader comes back it may hold conflicting writes (split brain). Followers only have what was shipped, not the dead leader's local WAL. Promotion does not need the old leader. Failover does not upgrade consistency.

Question 8

Users in the US and EU mostly write from their home region. Write latency must stay low, cross region RTT is 80 ms, and losing a few seconds of writes in a regional disaster is acceptable. Which setup fits?

Accepted Answer

Home each user in one region and replicate asynchronously to the other Homing users keeps writes local, and async replication gives a small RPO, which the constraints accept. Synchronous commits add at least 80 ms to every write. A single US leader makes EU writes slow and a US outage stops all writes. Last write wins across regions silently drops concurrent updates.

Sharding and replication system design questions

More system design topics

Practise these on your commute