Sign in to track progress, unlock prep layers, and browse your pipeline.Sign in
Design a KV store with QPS API
Distributed Key-Value StoresDistributed Counters and Metrics AggregatiHigh Availability and Fault ToleranceData Structures for Time-Series Data / SliNetwork Protocols and Inter-process Commun
Design a Key-Value Store with QPS API
Design a key-value (KV) store that supports basic read/write operations and also exposes an API to report Queries Per Second (QPS).
Functional Requirements
- Key-Value Operations:
Put(key, value): Stores or updates a value associated with a given key.Get(key) -> value | not_found: Retrieves the value for a given key, or indicates if the key is not found.
- QPS Query API:
GetQPS(windowSeconds) -> qps: Returns the QPS for a specified time window. The definition of QPS (e.g., system-wide, per-node, or per-key; counting all requests, onlyGetrequests, or only successful requests) should be clarified.
Non-Functional Requirements
- High Availability: The system should remain operational even in the event of component failures.
- Horizontal Scalability: The system should be able to handle increasing load by adding more resources. This is particularly relevant if the KV store operates in a cluster scope.
- Performance Impact: The QPS API should be fast and its operation should not significantly impact the performance of
GetandPutoperations.
Considerations for Discussion
Candidates should be prepared to discuss and clarify various aspects of the system, including:
- Scope of QPS: Is QPS measured cluster-wide, per single instance, or per-key? Is it overall QPS or specific to
Get/Putoperations? - Time Window Semantics: How is
windowSecondsinterpreted? Is it a last N seconds rolling window (sliding) or fixed wall-clock buckets? - Accuracy: What level of accuracy is required for QPS reporting? Are exact counts necessary, or are approximate counts with acceptable error bounds sufficient?
- Latency/SLA: What are the expected P99 latencies for
Get,Put, andGetQPSoperations? - Durability: Must stored values survive system restarts? What are the required Recovery Point Objective (RPO) and Recovery Time Objective (RTO)?
- Consistency: What consistency model is required for reads after writes (e.g., strong consistency, eventual consistency)?
- Scale: What are the expected key cardinality, typical value sizes, overall expected QPS, and potential for hot keys?
- Multi-tenancy: Is there a requirement to separate QPS reporting per tenant or application?
AI interview prep
Core dilemma
Balancing the low-latency, high-throughput requirements of a distributed KV store with the need for accurate, real-time, and scalable aggregation of operational metrics (QPS) without introducing significant overhead or contention.
Mid-level signals3
Senior signals3
Red flags3
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design a KV store with QPS API
Distributed Key-Value StoresDistributed Counters and Metrics AggregatiHigh Availability and Fault ToleranceData Structures for Time-Series Data / SliNetwork Protocols and Inter-process Commun
Design a Key-Value Store with QPS API
Design a key-value (KV) store that supports basic read/write operations and also exposes an API to report Queries Per Second (QPS).
Functional Requirements
- Key-Value Operations:
Put(key, value): Stores or updates a value associated with a given key.Get(key) -> value | not_found: Retrieves the value for a given key, or indicates if the key is not found.
- QPS Query API:
GetQPS(windowSeconds) -> qps: Returns the QPS for a specified time window. The definition of QPS (e.g., system-wide, per-node, or per-key; counting all requests, onlyGetrequests, or only successful requests) should be clarified.
Non-Functional Requirements
- High Availability: The system should remain operational even in the event of component failures.
- Horizontal Scalability: The system should be able to handle increasing load by adding more resources. This is particularly relevant if the KV store operates in a cluster scope.
- Performance Impact: The QPS API should be fast and its operation should not significantly impact the performance of
GetandPutoperations.
Considerations for Discussion
Candidates should be prepared to discuss and clarify various aspects of the system, including:
- Scope of QPS: Is QPS measured cluster-wide, per single instance, or per-key? Is it overall QPS or specific to
Get/Putoperations? - Time Window Semantics: How is
windowSecondsinterpreted? Is it a last N seconds rolling window (sliding) or fixed wall-clock buckets? - Accuracy: What level of accuracy is required for QPS reporting? Are exact counts necessary, or are approximate counts with acceptable error bounds sufficient?
- Latency/SLA: What are the expected P99 latencies for
Get,Put, andGetQPSoperations? - Durability: Must stored values survive system restarts? What are the required Recovery Point Objective (RPO) and Recovery Time Objective (RTO)?
- Consistency: What consistency model is required for reads after writes (e.g., strong consistency, eventual consistency)?
- Scale: What are the expected key cardinality, typical value sizes, overall expected QPS, and potential for hot keys?
- Multi-tenancy: Is there a requirement to separate QPS reporting per tenant or application?