Stop Saying "Just Use Redis": A Key-Value Store Cheat Sheet for System Design Interviews

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 of 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:

The 9 Key-Value Stores

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 or 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.