We’ve all been there. You sketch out a flawless high-level architecture on the whiteboard, and the interviewer leans in:
“Alright, what database are we using for this component, and why?”
My go-to response used to be a nervous, “Uh, Redis? Because it’s fast?”
Let me tell you from experience, that answer will get you a red flag faster than a race condition.
"Key-Value store" is a massive umbrella. Caching, configuration management, petabyte-scale storage—they all fall under KV, but choosing the wrong one exposes a lack of depth to your interviewer.
With so many databases out there, I always got tired comparing the nuances between different databases, so I distilled everything into a quick cheat sheet. Here are the 9 Key-Value stores you must understand for your next system design interview:
1. Redis: The Versatile In-Memory Giant
Redis isn’t just a cache, it’s an in-memory data structure store that natively understands lists, sets, sorted sets, and hashes.
Deploy when: Building rate limiters, leaderboards, or job queues where data structures matter and you need persistence across restarts.
Avoid when: Your dataset vastly exceeds available RAM.
2. DynamoDB: The Serverless Scaling Behemoth
Amazon’s fully managed NoSQL database that guarantees single-digit millisecond latency whether you have 1 megabyte or 1 petabyte of data.
Deploy when: You’re entrenched in AWS, need predictable performance at massive TPS, and want zero infrastructure management.
Avoid when: You require complex aggregations/joins.
3. FoundationDB: The ACID-Compliant Powerhouse
While most NoSQL databases sacrifice consistency for availability, FoundationDB maintains strict ACID transactions.
Deploy when: You need absolute correctness at scale (e.g., financial systems).
Avoid when: You just need a simple cache.
4. Cassandra: The Write-Optimized Workhorse
Technically a wide-column store, Cassandra thrives on massive ingest rates using LSM trees.
Deploy when: Handling write-heavy workloads (IoT sensors, chat logs) where high availability and eventual consistency are acceptable.
Avoid when: Your workload involves frequent updates/deletes or requires ACID transactions.
5. Riak: The Highly Available Dynamo Offspring
Riak prioritizes availability above all else. If a node goes down, Riak simply routes the write to a neighbor.
Deploy when: The system must stay up during network partitions (e.g., e-commerce shopping carts).
Avoid when: You need strict, immediate consistency for your reads and writes.
6. Etcd: The Distributed System’s Brain
If you’ve ever touched Kubernetes, you’ve interacted with Etcd. It exists to store system state, configuration, and metadata.
Deploy when: Building service discovery, managing distributed locks, or storing cluster configuration data.
Avoid when: You need to store large volumes of data.
7. RocksDB: The Embedded Speed Demon
RocksDB isn’t a standalone server; it’s a C++ library you embed directly into your application to squeeze every ounce of performance out of modern SSDs.
Deploy when: Building a custom database engine or needing blazingly fast, local, persistent storage.
Avoid when: You require a standalone networked database.
8. LevelDB: The Original Embedded KV Library
Created by Google legends Jeff Dean and Sanjay Ghemawat, LevelDB is the predecessor to RocksDB.
Deploy when: You need a lightweight embedded store for low-concurrency environments, like a mobile app or browser.
Avoid when: You have a high-concurrency server workload (pick RocksDB instead).
9. Memcached: The No-Nonsense Cache
Long before Redis dominated the scene, Memcached was the undisputed king of caching.
Deploy when: You need pure, raw caching power for simple, static objects and have vertical scaling capabilities.
Avoid when: You need persistence, advanced data types, or crash recovery.
The Takeaway
Don’t just drop names in a system design interview—talk about the trade-offs. If you propose Cassandra, explicitly state that you are trading strong consistency for high availability. If you choose Redis, acknowledge the RAM limitations.
Next time you’re asked to design a notification service, skip the generic “I’ll use a database.” Say “I’ll use Redis Pub/Sub.” That simple pivot shows senior-level engineering maturity.
💡 Want to dive deeper into the architecture, profiles, and exact "deploy vs. avoid" scenarios for each of these databases?
👉 Read the complete blog post on Medium here!
Top comments (0)