We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Database Types & Storage
The simplest NoSQL model: store data as key-value pairs. Blazing fast lookups by key. Redis, DynamoDB, and etcd are key-value stores.
In short
A key-value store is a database that saves data as a collection of key-value pairs, where each unique key maps to exactly one value, and you read or write data by referencing the key directly. It is the simplest NoSQL model and gives near constant-time lookups because retrieving a value is just a hash table lookup rather than a query that scans or joins tables.
In short
A key-value store is a database that saves data as a collection of key-value pairs, where each unique key maps to exactly one value, and you read or write data by referencing the key directly. It is the simplest NoSQL model and gives near constant-time lookups because retrieving a value is just a hash table lookup rather than a query that scans or joins tables.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Key-Value Store across a run of lessons, not one page. These 4 alone are about 141 minutes of step-by-step reading, every one with a quiz.
How key-value databases work, how to design good keys, and how Redis, DynamoDB and etcd compare. Includes a diagram of a GET and SET operation.
Design a distributed key-value store - LSM trees, compaction, consistent hashing, replication, tunable consistency, and failure detection.
Database model comparison, relational vs non-relational data stores.
Your database already cached the disk, so what a query cache saves is CPU, and that varies by 430 times between queries.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Key-Value Storespay once,
yours for life
Picture a dictionary or a hash map. You have a key like user:1042 and a value like the JSON blob describing that user. A key-value store is that same idea persisted as a database. You hand it a key, it hands you back the value. You do not write SQL, you do not define columns, and the store does not care what is inside the value.
The value is treated as an opaque blob in most pure key-value stores. It can be a string, a number, a serialized JSON object, a binary image, or a protobuf. The database does not parse it or index its contents. That is what keeps the model so simple and so fast.
Because there is no schema, two values under different keys can have completely different shapes. user:1042 might hold a profile while session:abc holds a login token with an expiry. The store does not enforce any structure across keys, which makes it a poor fit for ad hoc reporting but excellent for fast, predictable single-record access.
Lookups are fast because the key is run through a hash function that points more or less directly at where the value lives, either in memory or on disk. There is no table scan and no join planning. A get by key is roughly O(1), so a small read by key typically comes back in single-digit milliseconds or less, however many keys the store holds.
In-memory stores like Redis keep the whole dataset in RAM and use hash tables internally, which is why they answer in microseconds. Disk-backed stores like RocksDB and the engines behind DynamoDB use a log-structured merge tree (LSM tree): writes append to an in-memory buffer, get flushed to sorted files on disk, and background compaction merges those files. This makes writes very cheap and keeps reads fast through bloom filters and sorted indexes.
Distributing the data across many machines is done with partitioning. The key is hashed and that hash decides which node owns the key, usually through consistent hashing so that adding or removing a node only shuffles a small slice of keys. DynamoDB and Cassandra-style systems also replicate each key to several nodes for durability and availability, which is where tunable consistency (read your writes versus eventual consistency) comes in.
Reach for a key-value store when your access pattern is known in advance and is almost always by primary key. Session storage, user profiles fetched by id, shopping carts, feature flags, rate-limit counters, and caching layers in front of a slower database are the classic fits. If you can always answer with the key, this model is hard to beat on speed and scale.
The cost is query flexibility. You cannot say find all users in London who signed up last week unless you have built a separate index keyed on that question. There are no joins, no GROUP BY, and usually weak or no support for range scans across arbitrary fields. Every new access pattern means designing a new key or maintaining a secondary index yourself.
Many real systems use a key-value store alongside a relational database rather than instead of one. Postgres or MySQL holds the source of truth and supports rich queries, while Redis or DynamoDB serves the hot, high-volume reads. The other common gotcha is that in-memory stores are bounded by RAM, so you must set eviction policies and accept that data can be lost on a crash unless persistence or replication is configured.
Amazon built its internal Dynamo store, described in a 2007 paper and later the inspiration for the DynamoDB service, because the shopping cart needed to stay available even during failures and traffic spikes on days like Prime Day. The cart is stored as a value under a customer key. Reads and writes are single-key operations, replicated across multiple availability zones, and the system favors staying writable over perfect consistency so a customer can always add an item.
On the caching side, almost every large website puts Redis or Memcached in front of its database. When a request comes in for a product page, the app first checks Redis for product:5567. If it is there, the page renders in under a millisecond. If not, the app reads from Postgres, writes the result back into Redis with a time to live, and serves it. The next thousand requests for that product never touch the database.
Redis
In-memory key-value store used for caching, session storage, rate limiting, and leaderboards, answering in microseconds.
Amazon DynamoDB
Managed key-value and document store on AWS that powers shopping carts and high-traffic services with single-digit millisecond reads at any scale.
etcd
Strongly consistent key-value store that holds all Kubernetes cluster state, with every config and object stored under a key.
Memcached
Lightweight distributed memory cache used by Facebook and many others to store key-value pairs in front of databases.
A relational database stores data in tables with rows, columns, and a fixed schema, and lets you query across them with SQL, joins, and filters. A key-value store just maps a key to a value with no schema and no joins; you fetch data only by key. Relational wins on flexible querying, key-value wins on raw lookup speed and horizontal scale.
Yes. Redis is an in-memory key-value store, though it also supports richer value types like lists, sets, sorted sets, and hashes under each key. That makes it more than a plain string store while keeping the core key-based access model.
Avoid it as your only database when you need ad hoc queries, reporting, joins across entities, or filtering by fields other than the key. For example, find all orders over $100 from last month is awkward in a pure key-value store and trivial in SQL. Many teams use a relational database as the source of truth and a key-value store as a cache.
It hashes each key to decide which server owns it, usually with consistent hashing, so data spreads evenly across nodes. Adding a node only moves a small fraction of keys. Because every operation is a single-key get or put with no joins, each node handles its slice independently, which scales almost linearly.
No. The value is treated as an opaque blob, so it can be a string, number, JSON, serialized object, image, or any binary data. The store typically does not parse or index the contents; it just stores and returns whatever bytes you put under the key.
The industry examples in “The next question”:
Redis
An in-memory data store used as a cache, message broker, and database. Blazing fast because everything lives in RAM.
NoSQL
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
Document Database
A NoSQL database that stores data as flexible JSON-like documents. MongoDB and CouchDB let each document have a different structure.
Memcached
A simple, high-performance distributed memory caching system. Stores key-value pairs in RAM. Simpler than Redis but less feature-rich.
Column-Family Store
A NoSQL database that groups columns into families, optimized for reading and writing large amounts of data across many machines. Cassandra and HBase use this model.
Graph Database
A database built for storing and querying relationships between entities. Nodes are entities, edges are relationships. Neo4j is the most popular.
This page explains the idea. The "Key-Value Stores" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Key-Value Stores lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Key-Value Store in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
