Loading…

Design a Distributed Cache (Redis Cluster / DynamoDB) - SystemRound

Design a Distributed Cache (Redis Cluster / DynamoDB)

hardSystem design45 min5 stagesPro

Asked atAmazonGoogleMetaStripeNetflixDoorDash

Design a distributed in-memory key-value store / cache (like Redis Cluster, Memcached, or DynamoDB's storage layer) that partitions data across many nodes so the dataset exceeds one machine's memory, replicates each partition for availability, and stays fast (single-digit-millisecond) while surviving node failures and rebalancing as the cluster grows. The hard parts are choosing a partitioning scheme that doesn't reshuffle the world when a node joins, a replication + consistency model that trades off latency vs durability, and handling hot keys that overwhelm a single node.

Best after a few full reps. Expect follow-up questions, edge cases, and deeper trade-off discussion.

What this problem tests

Core APIsConsistency & AtomicityRequest RoutingPartitioningReplication & RoutingMembership

Round shape

5 stages

Time budget

45 min

Feedback loop

Grade anytime

Guided practice·Primary loop

Guided practice

Workspace-first, hints visible, stage retry available. The cheap, repeatable loop — build the answer shape before you take it under pressure.

Stage-by-stage workspace instead of a blank page.
Grade one stage or the whole answer whenever you want.
Compare your reasoning against reference criteria and model answers.

Solve once, compare against the checklist, then come back to the weak stage instead of starting over.

Mock interview·Pressure test

Mock interview

Strict timer, hints hidden, debrief deferred to the end. Use this once you can already structure a clean answer and want to pressure-test pacing and pushback.

Best once the answer shape is already in your head.
Pressure-test pacing, pushback handling, and communication.
Use diagnosis after the interview for exact misses and next study steps.

Best after one structured rep · timed · focused on pacing and communication.

Requirements

This is the framing pass. A strong answer quickly defines what the system must do, what quality bar it has to hit, and the numbers that will justify the rest of the design.

First 5 min of the round

What must exist

Functional Requirements

6 items

1GET(key), PUT(key, value), DELETE(key) for opaque values up to ~1 MB

2TTL / expiration on keys — keys auto-evict when expired

3Data partitioned across many nodes so the dataset exceeds one machine's memory

4Each partition replicated so a node or AZ failure loses neither data nor availability

5Nodes can join/leave with minimal key reshuffling (elastic cluster)

6Below the line: range scans, secondary indexes, multi-key transactions, pub/sub

What good looks like

Non-Functional Requirements

5 items

1Latency: p99 GET < 5ms, p99 PUT < 10ms within a region (in-memory)

2Scale: 1M+ ops/sec aggregate, 10 TB+ dataset, 100+ nodes

3Availability: 99.99% — survive single-node and single-AZ failure with no data loss

4Consistency (tunable): eventual by default; quorum (W+R>N, default N=3 W=2 R=2) for strong reads

5Durability (tunable): pure-cache mode (rebuildable, OK to lose) vs persistent mode (WAL + snapshot)

What to cover

The sharpest clarifying question

1 item

1is this a *pure cache* (rebuildable from a source of truth, eviction and restart loss are fine) or the *primary durable key-value store* (acknowledged writes must never be lost)? That one answer reshapes the durability and consistency design.

Numbers to anchor the design

Scale Estimation

3 items

110 TB at ~64 GB per node → ~160 nodes just to hold the data

2Replication factor 3 → ~30 TB stored, so memory budget triples

31M ops/sec across 100 nodes → ~10K ops/node on average (hot keys break this average)

How the round unfolds

Each stage has a distinct job. Treat them like separate deliverables instead of one giant answer, and the round becomes much easier to navigate.

4 design stages · 40 pts after framing

🔌

Stage 2~5 min10 pts

API Design

Define the contract clearly: the endpoints, auth boundary, error semantics, and the one or two decisions that matter most.

What you should produce

Define the API. What do GET / PUT / DELETE look like, and how does a client reach the right node?

Strong answers cover

Core APIsConsistency & AtomicityRequest Routing

🏗️

Stage 3~10 min10 pts

High-Level Architecture

Lay out the main components and trace the write path, read path, and any async path cleanly.

What you should walk through

Walk me through the architecture.

Strong answers cover

PartitioningReplication & RoutingMembership

💾

Stage 4~10 min10 pts

Data Model & Storage

Pick the store, show the schema or key model, and explain why that storage choice fits the access pattern.

What you should lock in

What lives on each node? How do you expire keys, evict under memory pressure, and persist for durable mode?

Strong answers cover

Per-Node StorageEvictionPersistence & Reconciliation

📈

Stage 5~15 min10 pts

Scaling & Deep Dive

Name the first bottleneck, failure modes, and the trade-offs that keep the system fast and reliable under pressure.

What you should pressure-test

Let's deep-dive the hard parts: a hot key getting 100K req/sec, rebalancing when a node joins, and what happens when a node dies.

Strong answers cover

Hot KeysRebalancing & FailureTuning & Observability

What a strong first rep looks like

Scope clearly

Translate the prompt into concrete requirements, scale, and trade-offs before drawing architecture.

Stay stage-specific

Give APIs in the API stage, data models in the storage stage, and failure modes in scaling. Don't blur them together.

Iterate fast

Grade early, compare to the reference reasoning criteria, fix the biggest misses, and re-submit the weak stage instead of starting over.