I Failed My First System Design Interviews. These 5 Concepts Were Why.

aashna mahajan — Sun, 24 May 2026 22:37:04 +0000

I failed three system design interviews in a row.

Not because I didn't know the concepts. I knew them cold. Caching, sharding, consistent hashing, CAP theorem, message queues — I could define every one.

What I couldn't do: answer what came next.

"What happens when the cache gets stale?"
"Why are you sharding this?"
"So you'd ignore partition tolerance?"

Every time, I had the surface answer. Every time, the follow-up question exposed that I'd never thought one level deeper.

These are the 5 places that gap cost me. Each one explained from scratch — with real code and real failure modes — so the follow-up question doesn't catch you off guard.

1. Everyone Adds a Cache. Almost Nobody Thinks About What Comes Next.

Your phone saves images from apps you visit so it doesn't re-download them every time. That's a cache — a faster copy of data, closer to the user.

In backend systems, instead of hitting a database on every request, you store hot data in something like Redis — an in-memory store that responds in under a millisecond. Instagram uses it to serve your profile. Reddit uses it to serve hot posts to millions of readers simultaneously.

A well-placed cache absorbs 80–95% of read traffic.

Here's how cache-aside — the most common pattern — looks in code:

def get_user(user_id: str):
    # Step 1: Check cache first
    cached = redis.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)        # Cache hit ✓

    # Step 2: Cache miss — go to the database
    user = db.find_one({"_id": user_id})

    # Step 3: Store result for next time (expires in 1 hour)
    redis.setex(f"user:{user_id}", ttl=3600, value=json.dumps(user))
    return user

# ⚠️ The hidden danger: what if the user updates their profile?
# If you forget: redis.delete(f"user:{user_id}")
# ...they'll see stale data for up to an hour.

Three strategies — each is right in one situation and quietly catastrophic in the wrong one.

I once watched a team spend three days debugging incorrect pricing at checkout. The cache populated correctly on product creation — but silently failed to invalidate when the price changed. Wrong prices served for six weeks. Code looked fine. Tests passed.

A cache without an invalidation strategy isn't a performance win. It's a time bomb with a clean interface.

💬 Interviewer follow-up you must answer: "How does the cache know when to invalidate?" Have that answer ready before they ask.

2. Sharding: Impressive on a Whiteboard, Painful in Production

I once watched a candidate spend 25 minutes designing a sharding strategy for a system serving 3,000 daily users.

Custom shard keys. Cross-shard routing. Resharding logic. The interviewer stopped him mid-sentence.

"Why are you sharding this?"

He didn't have an answer. He didn't get the job.

Over-engineering isn't ambition. It's anxiety wearing the mask of thoroughness.

Sharding splits your database across multiple servers — each one owns a slice of the data. It's real and powerful. It's also genuinely hard: joins across shards become painful, transactions need distributed coordination, and debugging requires knowing which shard holds your data.

The right order before you even think about sharding:

Exhaust every step before moving to the next. Most systems never need to go past step 2.

# ❌ Bad shard key — timestamp creates a "hot shard"
def get_shard(created_at: datetime) -> int:
    return hash(created_at) % NUM_SHARDS
    # All new writes hit the same shard. Others sit idle.

# ✅ Good shard key — user_id distributes evenly
def get_shard(user_id: str) -> int:
    return hash(user_id) % NUM_SHARDS
    # Load spreads evenly. No single shard gets hammered.

Instagram ran on a single Postgres instance far longer than most people realize. They only sharded when simpler options genuinely couldn't keep up.

💬 The answer that lands: Not "here's my sharding strategy." But "here's why I'd exhaust vertical scaling, read replicas, and caching first — and here's the signal that would tell me it's time."

3. Why Adding One Server Can Break Your Entire Cache

This one surprises people. Let's see it in code first.

# ❌ Naive modulo — breaks the moment you add a server
servers = ["server_1", "server_2", "server_3"]

def get_server(key: str) -> str:
    return servers[hash(key) % len(servers)]

get_server("user_123")   # → "server_2"

# You add a 4th server to handle more load...
servers.append("server_4")
get_server("user_123")   # → "server_1"  ← different server!

# Almost every key now maps somewhere new.
# Your entire cache just went cold. Enjoy the database stampede.

This is a real problem at scale. Adding one server to a cache cluster can invalidate most of your cached data at once — causing every request to hit the database simultaneously. That's an outage, not a scaling win.

Consistent hashing is the fix. Instead of key % N, both servers and keys are mapped onto a circular ring. Each key belongs to the nearest server clockwise.

Add a server? It takes only the keys between itself and its neighbor — roughly 1/N of data. Everything else stays put.

Adding one node displaces ~1/N keys. With naive modulo hashing, you'd be moving almost everything.

Redis Cluster, Cassandra, and DynamoDB all use consistent hashing under the hood. Akamai — one of the world's largest CDNs — was built on it. Their founders wrote the original academic paper on it.

💬 Why this matters in an interview: Most candidates skip this. Knowing why consistent hashing exists — not just what it is — signals you've thought seriously about distributed systems.

4. CAP Theorem Is Taught Wrong. Here's What It Actually Means.

I once confidently explained CAP theorem in an interview. The interviewer looked up and asked:

"So you'd consider building a system that ignores partition tolerance?"

I had nothing. The conversation got uncomfortable fast.

Here's the problem: CAP is almost always taught as "pick any two." That's misleading.

Partition tolerance — the ability to keep working when servers can't talk to each other — isn't optional. Networks fail. It will happen to your system. So the real choice is:

When a network partition occurs, do you prioritize consistency or availability?

	CP (Consistency first)	AP (Availability first)
Behaviour	Refuses requests until partition heals	Keeps responding, may return stale data
Risk	Downtime during failures	Stale reads
Use when	Payments, inventory, anything financial	Social feeds, recommendations, analytics
Examples	Postgres, CockroachDB, ZooKeeper	Cassandra, DynamoDB, CouchDB

Facebook chose AP for their social graph — a slightly stale follower count beats an app that won't load. A payments system needs CP — you'd rather reject a transaction than double-charge someone.

💬 The move: Don't just define CAP — apply it. "This is a payments system, so I'd use Postgres with synchronous replication. I'd rather reject a write during a network failure than risk charging someone twice."

5. Message Queues Don't Guarantee What You Think They Guarantee

Picture a restaurant on a Friday night. Orders are flying in faster than the kitchen can handle. If every waiter walked directly to a chef and demanded immediate attention, the kitchen collapses.

Instead: orders go on a ticket rail. Chefs work through them steadily. The kitchen stays calm no matter how busy the front gets.

That's a message queue.

Uber's trip events flow through Kafka. Netflix triggers encoding jobs through queues. Slack's notification pipeline is async. The pattern is everywhere.

Most candidates in interviews draw a queue, say "this decouples the services," and move on. That's not wrong. But here's what nobody mentions until they're paged at 3am:

Queues guarantee at-least-once delivery. Not exactly-once.

Your consumer will sometimes process the same message twice — a network timeout triggers a retry, or a crash causes redelivery. Without protection, a user gets charged twice, an email sends twice, a report generates twice.

def process_payment(message: dict):
    payment_id = message["payment_id"]

    # ✅ Idempotency check — safe to receive this twice
    if db.payment_already_exists(payment_id):
        print(f"Already processed {payment_id}. Skipping.")
        return

    # Process only if we haven't seen this before
    stripe.charge(message["amount"], message["card_token"])
    db.mark_payment_complete(payment_id)

# Without this: duplicate charge on retry.
# With this: second delivery is a no-op. ✓

Queue delivers to one. Pub/Sub delivers to all. Get this wrong and you'll either starve consumers or duplicate work across all of them.

The property that saves you is called idempotency — running an operation twice produces the same result as running it once. Stripe's payment API is idempotent by design. Every queue-based incident I've seen had idempotency missing somewhere.

💬 The line that stands out: "Consumers will check for duplicate message IDs before processing — queues guarantee at-least-once delivery, not exactly-once."

The Real Interview Starts Before You Pick Up the Pen

Every concept here has a surface answer and a real answer.

Surface answers get you through the definition check. Real answers — knowing that cache invalidation is harder than caching, that sharding is a last resort, that partition tolerance isn't optional, that queues will deliver your message twice — that's what separates candidates who studied from engineers who've built and broken these systems.

The candidate who got "exactly right" out loud didn't know more patterns than me. He asked one question before drawing a single box:

"What scale are we actually targeting here?"

That question. Every time. Before the pen touches the whiteboard.

Found this useful? I write about system design, engineering interviews, and real production systems. Follow along — more coming.