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 Onsite rounds at Meta.

What role is this question designed for?

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

Design a scalable key-value configuration service

Quick Overview

Design a scalable key-value configuration service 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 scalable key-value configuration service

Design a Globally Distributed Key–Value Configuration Service

Background

You are asked to design a globally distributed key–value configuration service powering thousands of microservices across multiple regions. The service should provide low-latency reads, strong safety for updates, and global availability.

Requirements

Define the key schema (namespacing, composability, versioning).
Define the value schema (serialization format, validation, schema evolution).
Explain partitioning/sharding, indexing, and storage engine choices (e.g., LSM-tree vs B-tree).
Describe write/read paths and hot-key mitigation.
Specify the consistency model (linearizable vs eventual), leader election, replication/quorums, and handling of network partitions and failover.
Describe support for transactions, watches/subscribe for updates, TTLs, and backup/restore.
Provide capacity planning, SLAs, multi-region replication strategy, and testing approaches.

Assumptions

Read-heavy (≫95% reads), small values (0.5–8 KB), small key space (≤ few million keys), but very high fanout of clients.
Writes are rare but correctness-critical; clients expect fast propagation of changes.
Multi-tenant namespaces, multi-region footprint, thousands of services, tens of thousands of instances.

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 Guidance

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 Guidance

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 Guidance

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

Requirements

Define the key schema (namespacing, composability, versioning).

Define the value schema (serialization format, validation, schema evolution).

Explain partitioning/sharding, indexing, and storage engine choices (e.g., LSM-tree vs B-tree).

Describe write/read paths and hot-key mitigation.

Specify the consistency model (linearizable vs eventual), leader election, replication/quorums, and handling of network partitions and failover.

Describe support for transactions, watches/subscribe for updates, TTLs, and backup/restore.

Provide capacity planning, SLAs, multi-region replication strategy, and testing approaches.

Assumptions

Read-heavy (≫95% reads), small values (0.5–8 KB), small key space (≤ few million keys), but very high fanout of clients.

Writes are rare but correctness-critical; clients expect fast propagation of changes.

Multi-tenant namespaces, multi-region footprint, thousands of services, tens of thousands of instances.

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 Guidance

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 Guidance

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 Guidance

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 scalable key-value configuration service

Quick Overview

Design a scalable key-value configuration service

Design a scalable key-value configuration service

Design a Globally Distributed Key–Value Configuration Service

Background

Requirements

Assumptions

Constraints & Assumptions

Clarifying Questions to Ask Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Submit Your Answer to Earn 20XP

Design a scalable key-value configuration service

Quick Overview

Design a scalable key-value configuration service

Design a scalable key-value configuration service

Design a Globally Distributed Key–Value Configuration Service

Background

Requirements

Assumptions

Constraints & Assumptions

Clarifying Questions to Ask Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Submit Your Answer to Earn 20XP