Design a KV store with QPS API

Q: Design a KV store with QPS API

This question evaluates a candidate's ability to design scalable, highly available key-value storage systems and to integrate real-time metrics reporting such as QPS, testing competencies in distributed systems architecture, data durability, consistency, and observability.

Q: 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.

Question

Loading...

Design a key-value (KV) store that supports basic read/write operations and also exposes an API to report QPS (queries per second).

Functional requirements

Support:
- Put(key, value)
- Get(key) -> value | not_found
Provide a QPS query API, e.g.:
- GetQPS(windowSeconds) -> qps
- (Clarify if QPS is system-wide , per-node , or per-key ; and whether it counts all requests or only Get / only successful requests.)

Requirements to clarify (ask the interviewer)

Scope of QPS : cluster-wide vs single instance; overall vs per-key.
Time window semantics : last N seconds rolling window (sliding) vs fixed wall-clock buckets.
Accuracy : exact vs approximate; acceptable error bounds.
Latency/SLA : expected p99 for Get / Put and for GetQPS .
Durability : must values survive restarts? required RPO/RTO.
Consistency : strong vs eventual for reads after writes.
Scale : key cardinality, value sizes, expected QPS, hot keys.
Multi-tenancy : separate QPS per tenant/app?

Non-functional requirements

High availability and horizontal scalability (if cluster scope).
QPS API should be fast and not significantly impact Get/Put performance.

Design a KV store with QPS API

Quick Overview

Functional requirements

Requirements to clarify (ask the interviewer)

Non-functional requirements

Solution

Comments (0)