Design a scalable key-value store across multiple nodes.

Question

Anonymous · Accepted Answer

Before I jump into the architecture, I want to clarify the requirements, because
the consistency, availability, and scaling choices will drive the design.

Functional

* Do we need just PUT and GET, or also DELETE?

* Are keys strings? What is the maximum key size?

* What is the maximum value size?

* Do we need TTL/expiration?

* Do we need atomic operations such as compare-and-set?

* Do we need transactions across multiple keys?

Assume:

* PUT(key, value)

* GET(key)

* DELETE(key)

* TTL

* No multi-key transactions.

Non-functional

Then I’d ask:

“What scale are we targeting?”

For example:

* 100 million keys

* 100K requests/sec

* 80% reads / 20% writes

* Low latency, say <10–20 ms at p99

* Highly available

* Data must survive node failures.

And most importantly:

“What consistency model do we need?

Let’s assume strong consistency for a single key, while prioritizing
availability where possible.

Clients

|

v

+--------------+

| Load Balancer|

+--------------+

|

v

+------------------+

| Key-Value Servers |

| |

| Node 1 |

| Node 2 |

| Node 3 |

| ... |

+------------------+

|

+-------------+

| Membership / |

| Metadata |

+-------------+

For read-heavy workloads, something like Redis could absorb a huge number of
reads.

For a hot key we can also replicate reads across multiple replicas, depending on
consistency requirements.

But I would explicitly say:

“Caching is easier for eventually consistent reads. If the API requires strongly
consistent reads immediately after writes, cache invalidation and read routing
need to be carefully designed.”

Design a scalable key-value store across multiple nodes.

Practice this question with AI

Go Premium

Community Answers

Unlock Full Access

Practice More Questions