But what happens when traffic increases tenfold?

Does Redis protect your database? Does the database become the bottleneck? What happens when Redis goes down and every request starts hitting the database directly?

These are the questions that make system design interesting.

The problem with learning system design

A lot of system design learning starts with architecture diagrams. You learn about load balancers, caching, database replication, queues, and horizontal scaling.

That's important, but knowing what a component does isn't the same as understanding how a system behaves when those components interact.

A cache might reduce database load under normal traffic. But if the cache fails, the database suddenly receives requests it wasn't sized to handle.

A queue might absorb traffic spikes. But if workers process messages more slowly than they arrive, the backlog keeps growing.

Adding more servers might increase capacity, but only if the bottleneck isn't somewhere else.

The interesting part isn't just designing the happy path. It's understanding what happens when your assumptions stop holding.

Let's take a URL shortener

Imagine you're building a service like bit.ly.

At a high level, you might have:

• An API gateway to receive requests
• An application service to resolve short URLs
• Redis to cache popular mappings
• PostgreSQL to store the mappings permanently

At low traffic, this architecture might work perfectly well.

Now imagine traffic grows significantly.

Scenario 1: The database becomes the bottleneck

If most requests are reads and Redis handles the majority of them, the database may remain healthy.

But as traffic grows, cache misses and writes still reach PostgreSQL. Eventually, database capacity can become the limiting factor.

The first instinct might be to add more application servers. That won't necessarily help if the database is already saturated.

The better question is: which component is actually limiting throughput?

Scenario 2: Redis goes down

Without a cache, requests that previously hit Redis may fall through to PostgreSQL.

The database now receives a much larger share of the traffic. If it cannot handle that load, latency increases and requests begin to fail.

A component that was supposed to improve performance has become a dependency whose failure affects the entire system.

This is why it's important to think about failure behavior, not just normal operation.

Scenario 3: You add more application servers

More application servers can help if application processing is the bottleneck.

But if the database is already saturated, adding servers may simply allow more requests to reach the overloaded database.

Scaling a system means identifying the constraint and addressing it, not blindly increasing the number of machines.

Learn by experimenting

This is why I wanted a more hands-on way to learn system design.

Instead of only looking at a diagram and guessing what might happen, I wanted to build an architecture, change the traffic, and observe how the system responds.

I've been building StackMonkey to explore exactly this.

It's a free, browser-based playground where you can build system architectures, simulate traffic, and investigate bottlenecks and failure scenarios.

You can start with a URL shortener, change the load, and explore how different components affect the system.

It's a learning simulator, not a replacement for production load testing. The results depend on the models and assumptions used, so they shouldn't be treated as guarantees of real-world performance.

The goal isn't to memorize diagrams

When preparing for system design interviews, it's tempting to memorize a standard architecture for every popular question.

But interviewers can change the requirements, increase the traffic, or ask what happens when a dependency fails.

Understanding the underlying trade-offs helps you reason through those changes.

When you design a system, ask yourself:

• What is the current bottleneck?
• What happens when traffic doubles?
• What happens when a dependency fails?
• Will adding capacity actually help?
• What trade-off am I making with this design?

You don't need a perfect answer to every question. You need a way to reason about the system and explain why you made your decisions.

That's the kind of learning I want StackMonkey to encourage.

If you're learning system design or working on backend systems, give StackMonkey a try. I'd love to hear what you find useful, what feels confusing, and what you'd like to experiment with next.