System Design Interview Question: Design a Key-Value Store (like DynamoDB) in 45 Mins

The ultimate Key-Value Store design guide. From functional requirements to cluster diagrams, learn the 14 steps to architecting a system like Amazon DynamoDB.

1. Problem Definition and Scope

We are designing a distributed Key-Value (KV) store. This is a NoSQL database that allows applications to store data as a collection of key-value pairs, where the key is a unique identifier and the value is opaque binary data (the system does not need to understand the content).

• Main User Groups:

  • Application Developers: They use the KV store as the backend for microservices (e.g., storing user sessions, shopping carts, or product preferences).

  • System Administrators: They manage the cluster hardware, although the system should be largely self-healing.

• Scope: We will focus on the backend architecture required to store, retrieve, and replicate data at scale.

  • In Scope: Data partitioning (sharding), replication, consistency models (tunable), read/write paths, and handling node failures.

  • Out of Scope: Multi-region replication (we will focus on a single region with multiple availability zones), complex SQL querying, billing, and user authentication.

2. Clarify Functional Requirements

Must Have:

• Put(key, value): Users can store or update a value associated with a key.

• Get(key): Users can retrieve the value associated with a key.

• Delete(key): Users can remove a key-value pair.

• Configurable Consistency: Users can choose between strong consistency (slower) or eventual consistency (faster) for each request.

• High Availability: The system must accept writes even if some nodes are down.

Nice to Have:

• Versioning: Support for version numbers or timestamps to handle concurrent updates.

• TTL (Time To Live): Automatically delete keys after a certain time expiration.

3. Clarify Non-Functional Requirements

• Scale: Support 100 TB of data and billions of keys.

• Throughput: 100,000 queries per second (QPS).