Master System Design Interviews on the Go

Sharding is a type of database partitioning that separates very large databases into smaller, faster, more easily managed parts called data shards. It is a form of horizontal scaling. Key challenges include choosing the right shard key (to avoid hot partitions), cross-shard joins (which are slow and complex), and resharding (moving data when a shard gets too full).

In an interview: Lead with the partition key — it decides whether horizontal scaling actually works or just relocates the bottleneck into one hot shard. Cross-shard joins and resharding are the follow-ups interviewers always reach for.

• Partition key
• Horizontal scaling
• Hot partition
• Resharding
• Write throughput

Consistent hashing maps both servers and keys onto a fixed circular hash ring, and each key is owned by the first server encountered clockwise. When a node is added or removed, only the keys in its immediate arc are remapped — on average K/N keys — instead of nearly all keys as with a naive hash-mod-N scheme. Virtual nodes (many ring positions per physical server) are used to smooth out uneven load and hotspots. It underpins distributed caches and databases such as Amazon Dynamo, Cassandra, and many CDN routing layers.

In an interview: Hash-mod-N remaps almost everything on a membership change; the ring remaps roughly K/N. Bring up virtual nodes for even load across heterogeneous hardware, and be ready to say it does nothing for a single hot key.

• Hash ring
• Virtual nodes
• Rebalancing
• Cache miss storm
• Key distribution

Raft is a consensus algorithm designed to manage a replicated log, heavily used in distributed systems to maintain state machine consistency across nodes (e.g., in etcd or Consul). It breaks consensus down into Leader Election, Log Replication, and Safety. Nodes exist in one of three states: Leader, Follower, or Candidate. It requires a majority quorum to commit entries, ensuring that network partitions don't lead to split-brain scenarios.

In an interview: Decompose it the way Raft does — leader election, log replication, safety — and anchor every claim on majority quorum: a minority partition can never commit, so failover is automatic and split-brain becomes structurally impossible rather than merely unlikely.

• Consensus
• Quorum
• Leader election
• Replicated log
• Split-brain

The dual write problem occurs when a single operation must update two independent systems — for example a database and a message broker — without a shared transaction. If the process crashes after the first write but before the second, the systems drift out of sync and there is no automatic way to reconcile them. The standard fixes are the Transactional Outbox pattern (persist the event in the same DB transaction, then relay it asynchronously) or Change Data Capture (CDC), which streams the database's commit log to downstream consumers so the log is the single source of truth.

In an interview: Name it as a missing distributed transaction, then reach for the transactional outbox or CDC so the commit log becomes the single source of truth for every downstream microservice. Say plainly that you buy atomicity with eventual consistency — and that at-least-once delivery makes consumer idempotency mandatory.

• Transactional outbox
• Change data capture
• Idempotency
• At-least-once
• Eventual consistency

When under extreme stress, a system must protect itself. 'Load Shedding' purposefully drops low-priority requests (returning 503) to ensure critical requests succeed. The 'Bulkhead' pattern (named after ship compartments) isolates resources. For example, assigning a strict maximum of 10 threads to Service A ensures that if Service A hangs, it won't consume all CPU threads, allowing Service B to continue operating normally.

In an interview: Shed low-priority load early with a 503 so critical paths keep their capacity, and bulkhead a thread pool per dependency so one hanging service cannot starve the whole process. Degrading deliberately beats collapsing uniformly — and it keeps tail latency bounded for the traffic you do serve.

• Load shedding
• Bulkhead
• Thread-pool isolation
• Backpressure
• Tail latency