How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Confluent.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Confluent during technical interviews.

Design a distributed key-value store at scale | Confluent Interview Question

Quick Overview

Design a distributed key-value store at scale evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a distributed key-value store at scale

System Design Prompt: Globally Distributed, Read-Optimized Key-Value Store

Context and minimal assumptions

Design a globally distributed key-value (KV) store optimized for read-heavy workloads. Assume:

Workload: 90–95% reads, 5–10% writes; point lookups dominate, range scans are rare.
Data model: opaque values by key; keys up to ~1 KB; median value ~1 KB (max 1 MB).
Scale: tens of TB per region; multi-tenant; multi-region across continents.
Latency targets: in-region p99 read ≤ 5–10 ms; global p99 read ≤ 150 ms via nearest region.
Availability/durability: ≥ 99.99% availability; RPO 0 within a region; cross-region replication tolerated to be async by default.

Task

Propose an end-to-end design and justify your choices. Address the following areas with performance, complexity, and resource trade-offs:

OS-level performance considerations (threads vs async I/O, context switching, memory management, filesystem and kernel tuning).
Storage layout and indexing (on-disk format, compaction strategy, write amplification trade-offs).
Partitioning and sharding (key distribution, shard sizing, rebalancing strategy).
Replication and caching layers (write/read paths, coherence, TTLs, invalidation strategies).
Consistency models and CAP/PACELC trade-offs (client-visible guarantees and tunable options).
Failure detection, fault isolation, leader election, recovery and repair.
Hotspot mitigation, backpressure, and rate limiting (per-tenant fairness and overload control).
Capacity planning, SLAs/SLOs, and observability (metrics, tracing, alerting; how to validate the design).

Be explicit about assumptions, call out pitfalls/edge cases, and use small numeric examples where helpful.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Quick Overview

Context and minimal assumptions

Design a globally distributed key-value (KV) store optimized for read-heavy workloads. Assume:

Workload: 90–95% reads, 5–10% writes; point lookups dominate, range scans are rare.

Data model: opaque values by key; keys up to ~1 KB; median value ~1 KB (max 1 MB).

Scale: tens of TB per region; multi-tenant; multi-region across continents.

Latency targets: in-region p99 read ≤ 5–10 ms; global p99 read ≤ 150 ms via nearest region.

Availability/durability: ≥ 99.99% availability; RPO 0 within a region; cross-region replication tolerated to be async by default.

Task

Propose an end-to-end design and justify your choices. Address the following areas with performance, complexity, and resource trade-offs:

OS-level performance considerations (threads vs async I/O, context switching, memory management, filesystem and kernel tuning).

Storage layout and indexing (on-disk format, compaction strategy, write amplification trade-offs).

Partitioning and sharding (key distribution, shard sizing, rebalancing strategy).

Replication and caching layers (write/read paths, coherence, TTLs, invalidation strategies).

Consistency models and CAP/PACELC trade-offs (client-visible guarantees and tunable options).

Failure detection, fault isolation, leader election, recovery and repair.

Hotspot mitigation, backpressure, and rate limiting (per-tenant fairness and overload control).

Capacity planning, SLAs/SLOs, and observability (metrics, tracing, alerting; how to validate the design).

Be explicit about assumptions, call out pitfalls/edge cases, and use small numeric examples where helpful.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.

If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.

Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.

State explicit assumptions before making sizing or architecture decisions.

Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers

A scoped requirements summary with concrete non-goals and success metrics.

API, data model, architecture, consistency, capacity, and operations.

Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.

A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions

What breaks first at 10x traffic or data volume?

How would you degrade gracefully during dependency failures?

What metrics and alerts would prove the design is healthy after launch?

Design a distributed key-value store at scale

Quick Overview

Design a distributed key-value store at scale

Design a distributed key-value store at scale

System Design Prompt: Globally Distributed, Read-Optimized Key-Value Store

Context and minimal assumptions

Task

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP

Design a distributed key-value store at scale

Quick Overview

Design a distributed key-value store at scale

Design a distributed key-value store at scale

System Design Prompt: Globally Distributed, Read-Optimized Key-Value Store

Context and minimal assumptions

Task

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP