Redis is Not What You Think It Is.

It's not just a cache.
For years, we've put Redis in a tiny box labeled "fast, in-memory cache".
But I spent over 100 hours watching it in production, and what I saw changed my mind completely.
It’s a beast, and most of us are only using 10% of it.

​
The Great Database Divide

Here’s a problem we all face: we need our applications to be both fast and reliable.
We need to retrieve data instantly, but we also can't afford to lose it if the server crashes.
It’s a constant war between speed and safety.

​

Fast vs. Safe: The Old Way

The classic solution is to use two different tools for the job:
We grab Redis for its lightning speed and use it for short-lived information.
This is the Redis we all know.
You set a key with an expiration time:

and poof, it's gone when you need it to be - in this instance, 3 seconds later.
Then, for the "important" stuff, we use a traditional database, like a sqlite or postgresql.
The thinking is simple: cache equals fast, database equals safe.
But Redis, can do both!!
​

Redis: Your Fast AND Safe Database

So, how do I solve it differently.
When I can, I use Redis for both.

Redis is way more than a simple k/v store.
It has built-in data structures like hashes, which are perfect for storing entire objects, just like a document in a nosql database.
You can store a user with their ID, email, name, and login count, all under a single key with

But what about safety you ask?
What happens if the server restarts?
By default, Redis does occasional snapshots, which aren't reliable enough for critical data.
But there's a feature that changes everything: the Append Only File, or AOF.

By turning on AOF with

you tell Redis to log every single write operation to a file.
​Every. Single. One.​
If the server crashes, Redis simply replays this log to restore its state perfectly.
Suddenly, your in-memory cache is a durable, persistent database.

You can even create your own indexes -
Let’s say you need to find a user by their email.
You can create a key that maps the email address directly to the user's ID, giving you a super-fast lookup with

And what about handling things like unique usernames.
Redis has Sets, which are unordered buckets of unique data.
You can add a username to a set with

and Redis will automatically reject any duplicates.

Finally, for the ultimate database feature, what about race conditions?
You can use a transaction:
You tell Redis to watch a key with

Then you start a transaction with

and queue up your commands, like

If another client changes that key before you run

the entire transaction is aborted.
No more corrupted data.

You get the speed of in-memory with the reliability of a traditional database.
All in one tool you're probably already using.

And this, is how you achieve in memory speed, with DB persistence achieving the fastest database you can think of.

Yes, it comes with a price, but this debate is for another week :)

Thank you for reading.

Feel free to reply directly with any question or feedback.

Have a great weekend!