I Stopped Blaming Redis for Bad Architecture Decisions

Three years ago, I sat in a system design interview and confidently said, "We'll use Redis." The interviewer stared at me for what felt like an eternity, then asked, "Why?" I froze. I had no answer beyond "it's fast." That's when I realized I'd been defaulting to the same tools across completely different problems—not because they fit, but because they were familiar.

What bothered me most wasn't that I failed the interview. It was that I'd been doing the same thing in production. I'd reach for Redis, DynamoDB, or Postgres like they were interchangeable ingredients. The difference between knowing what a database does and understanding when to use it? That gap cost me real debugging sessions, scaling headaches, and conversations with frustrated DevOps teammates asking why we picked the wrong tool.

This article forced me to stop and actually think about what I was choosing and why.

The Problem Isn't the Tools—It's the Reasoning

Let me be honest: the original article's core message resonates because it's true. We do throw database names around carelessly. But I'd push deeper here. The real issue isn't that developers say "just use Redis." It's that we've created a culture where sounding confident matters more than thinking clearly.

In Islamabad-based teams I've worked with, I've seen this happen constantly. A junior engineer proposes DynamoDB for their notification system because they saw it on AWS's homepage. A senior dismisses it without explaining why Postgres might be better. Nobody actually discusses trade-offs anymore—we just pick what we know.

The cheat sheet approach helps, but only if you understand the why behind each choice.

Understanding the Real Dimensions

The article groups nine key-value stores, but I think there are five dimensions that actually matter when choosing:

Consistency guarantees. Redis is eventually consistent if you're running replicas. FoundationDB gives you ACID transactions. DynamoDB sits somewhere in between. What does your use case tolerate?

Persistence vs. speed. Redis lives in RAM—blazingly fast but requires your entire dataset to fit in memory. RocksDB and LevelDB are embedded libraries that trade some speed for durability and don't need network hops.

Operational complexity. Etcd manages itself alongside Kubernetes. Cassandra demands operational expertise most teams don't have. Memcached is dead simple. What's your team's bandwidth?

Data structure support. This one gets overlooked. Redis understands sorted sets and hashes natively. DynamoDB does not. That shapes what queries you can actually run.

Scalability direction. Cassandra scales horizontally through sharding. Redis scales vertically until you hit RAM walls. They're solving different problems.

What I'd Do Differently

Here's where I disagree with the cheat sheet approach: it doesn't address the real conversation you should have in an interview.

Instead of memorizing nine databases, I'd focus on understanding two or three deeply and being honest about the rest. When an interviewer asks about your database choice, don't rattle off features. Walk them through your reasoning. "We need high-throughput writes with eventual consistency, so I'm considering Cassandra. But we also need to handle complex queries, so we might need a read replica in Postgres. Here are the trade-offs we'd navigate."

That's the conversation that separates thinking developers from tool-hoarders.

I also think the article undersells Postgres. For 80% of systems being designed in interviews, you can probably use Postgres with a Redis cache in front. It's not sexy, but it works, it scales, and your team knows how to operate it. The temptation to reach for specialized databases often comes from reading architecture posts about companies with billion-user problems—problems you don't have.

Code Sketch: Thinking Through a Choice

Here's how I'd approach database selection in practice:

Requirements Analysis:
├── Read/Write ratio? (impacts caching strategy)
├── QPS expectations? (impacts scalability needs)
├── Consistency requirements? (impacts replication model)
├── Data volume? (impacts storage approach)
├── Query patterns? (impacts index design)
└── Team expertise? (impacts operational burden)

Decision Tree:
├── If consistency matters + complex queries → Postgres + Redis cache
├── If consistency matters + simple KV + massive scale → DynamoDB
├── If write-heavy + eventual consistency OK → Cassandra
├── If single machine + need speed → RocksDB
└── If config/discovery → Etcd

This isn't a cheat sheet—it's a thinking process.

The Real Takeaway

The article is right about one thing: showing your reasoning matters more than knowing the answer. But the deeper lesson is that there's no substitute for understanding your specific problem first. Memorizing database comparisons won't help if you don't know why you're comparing them.

Next time you're designing something, resist the urge to name-drop. Instead, ask yourself: Why is this the least bad choice for this specific problem? If you can answer that clearly, you're already ahead.

What's a database choice you've regretted in production? I'd genuinely like to know what made you question it.

Source: This post was inspired by "Stop Saying "Just Use Redis": A Key-Value Store Cheat Sheet for System Design Interviews" by Dev.to. Read the original article