Why I reached for Redis on a 200-line project

A short, plain-language explanation of where one specific tool earns its keep.

I built a small project to answer a question I ask myself: "Do I actually need Redis?" Redis is a tool a lot of developers reach for, sometimes for very good reasons and sometimes out of habit. I wanted a tiny, clear example of where it really does the work it claims to do.

The project is a small program that pretends to be a weather service. When you ask it for the weather in London, it goes off to a (deliberately slow) outside provider, fetches the answer, and sends it back. That's it. About 200 lines of code in total. Inside that little program, Redis is quietly doing two specific jobs, both of which would be a real pain to do without it.

The problem

Imagine your business depends on calling a service that someone else runs. Pick any example you like: a weather provider, a currency exchange feed, a stock-price feed, a customer relationship system. These services tend to share three annoying traits at once. They're slow (one call takes most of a second). They charge you per request. And they limit how many times you're allowed to ask in a given window.

If you don't think about it, two problems show up almost immediately:

It's slow for every single user. Even though the weather in London doesn't really change in the next ten seconds, every user who asks waits a full second for the answer. The site feels sluggish.

It costs money fast and is easy to abuse. If someone (or a bot) decides to hammer your service in a loop, they can burn through your daily quota with the outside provider in minutes. The bill goes up. And your real users start getting blocked, because the provider now thinks you are the abuser.

Both of these problems share a shape. They're about reading the same kind of information many times, where it's perfectly fine if the answer is a tiny bit out of date. Which is exactly the situation Redis exists for.

What Redis actually is

A useful one-line description: Redis is a very fast scratchpad. Most "real" databases save their information to a hard drive, which is durable but slow. Redis keeps its information in memory, which is much faster but doesn't survive a power cut. For things that change quickly and don't need to be remembered forever, that trade is exactly right.

It also comes with a small set of cleverly chosen operations: save a value, fetch a value, count something up by one, and (importantly) automatically delete a value after a chosen number of seconds. You'd be surprised how much you can build out of just those four things.

Job 1: Remember the answer

The trick is straightforward. The first time someone asks for the weather in London, my program goes off and fetches it from the slow outside provider. It sends the answer back to the user, and it tucks a copy of the answer onto the Redis scratchpad with a little expiration label: "this is good for 60 seconds."

The next time anyone asks for London weather in those 60 seconds, my program checks Redis first, finds the saved answer instantly, and skips the slow provider entirely.

That's the whole pattern. Boring on paper. But the effect is striking:

Request #1 (first one in)   ~877 ms
Request #2 (already saved)    ~7 ms
Request #3 (already saved)    ~5 ms
Request #4 (already saved)    ~4 ms
Request #5 (already saved)    ~5 ms

The first request is the slow one. Every request for the next minute is roughly 150 times faster, because we're just reading from the scratchpad. One real call serves a hundred users for the next minute. The bill from the outside provider drops in proportion. On a recent client project, doing exactly this cut their monthly costs by about 94%.

A reasonable question: why use Redis for this instead of just remembering the answer inside my own program? A few practical reasons:

• More than one machine. Real websites often run several copies of the same program at once, so they can handle more traffic. Each copy has its own memory. If I "remembered" the answer inside just one copy, the other copies would still have to go fetch it themselves. Redis is a shared place that all the copies can read from.
• The scratchpad survives a restart. Every time I update my code and redeploy it, the program restarts and forgets everything. Redis keeps going. The saved answers are still there waiting.
• Expiration is free. Telling Redis "this is good for 60 seconds" means I never have to write code to clean up old entries. They quietly disappear on their own.

Job 2: Stop one person from ruining it for everyone

The second job is what's called rate limiting. The idea: each user gets a budget. They're allowed twenty requests per minute. After that, they have to wait until the next minute starts.

The way to do this with Redis is almost embarrassingly simple. For each user, I keep a counter on the scratchpad. Every time they make a request, the counter goes up by one. If the counter goes over twenty, I send them a polite "slow down for a moment" message instead of doing the work. After a minute, the counter resets to zero on its own, using the same automatic-expiration trick.

The really clever bit is something most people never think about. If twenty people all hit my site at the exact same instant, you might worry that the counter could get confused. Which request was "number 5"? Which was "number 6"? Redis is designed so that operations like "add one" can't get tangled up, even under huge simultaneous load. The count always comes out right.

That single property is why this is fifteen lines of code instead of fifty. Without that guarantee, I'd have to write a lot of careful protective scaffolding around the counter to keep two requests from stepping on each other's toes.

A small but important touch: fail open

One detail worth mentioning. If Redis itself somehow becomes unreachable (a network glitch, a server hiccup), my code is set up to let the request through rather than reject it. The reasoning: rate limiting is a useful protective layer, but if it breaks, breaking the whole website along with it would be a worse outcome than letting a few extra requests slip past for a minute.

That kind of decision doesn't matter until the day it matters. The day Redis blinks is the day you're glad you wrote it that way.

What I didn't use Redis for

It's worth being clear about what Redis isn't doing in this project, because it's tempting to reach for a familiar tool for everything.

• It's not the main database. There isn't one in this project, but if there were, Redis wouldn't replace it. For information that needs to be remembered forever (user accounts, orders, transactions), you still want a proper database.
• It's not running background tasks. Some Redis features support that, but I didn't need them here.
• It's not delivering live notifications. Same answer. I didn't need it. Don't pile in features just because the tool happens to offer them.

The discipline of choosing a tool is the same as choosing any other thing in life. Pick the one that fits the specific problem, and don't reach for the rest of its features just because they're sitting there.

Takeaways

If you're building anything online, and any of these are true, Redis is probably worth the small amount of effort to add:

• You make calls to a slow or expensive outside service, and the answer can be a little out of date.
• You need to count something safely while a lot of things happen at once.
• You want short-lived information (login sessions, one-time codes, password reset tokens) that should disappear on its own.

You don't need it for everything. You don't need it for most things. But when your problem matches the shape of the few simple operations it's built for, the problem just quietly goes away. You almost forget the tool is there.

Which, honestly, is the highest compliment I can pay any piece of infrastructure.