Redis explained in 8 minutes

Added: 2026-05-30

[00:00:00]Most developers start using Redis when their database gets slow and the API starts showing higher latency.

[00:00:05]In that case, someone will probably tell you to use cache. So, you set up Redis, store some data in it, and suddenly latency drops and everything is fine.

[00:00:13]For a lot of us, the mental model of Redis stops right there. We think of it as a temporary box for key-value pairs, a simple hash map running in memory that loses all its data the moment the server reboots. But if Redis is just a temporary dumb cache, why do modern tech stacks use it for a lot of stuff like, for example, message brokering, real-time analytics, geospatial tracking, or even as a primary persistent database? The truth is, saying that Redis is only for caching is like saying a phone is only for ringing.

[00:00:42]It's technically true, but it misses a lot of things. So, in this video, we will look at what's happening under the hood of Redis to understand how it actually works, why it's single-threaded, and how it manages to be both insanely fast and persistent at the same time. Let's start with the most obvious question. Why is Redis so much faster than a traditional database? If you query a relational database, the engine has to do a lot of work. It parses the SQL query, plans the execution, traverses a B-tree index, and eventually reads the data.

[00:01:12]But the biggest bottleneck is that data lives in the disk. Even with modern NVMe SSDs, disk access is measured in microseconds. As you probably know, Redis takes a different approach. It is in-memory data structure store, so it bypasses the disk for read and write operations. The data lives in RAM, and reading from it takes nanoseconds. The operations done on RAM are a lot faster compared to disk operations.

[00:01:36]But raw speed isn't enough. If you just wanted to store data in RAM, you could declare a global variable in your Node or Python back end, and it would do the same job.

[00:01:45]What makes Redis powerful is the second part of its definition, data structure store.

[00:01:51]Traditional caches only understand strings. You give them a key, and they store a massive blob of text. If you want to update one field in cached JSON object, you have to retrieve the entire string, then parse it, then update the data, then stringify it, and finally, you can save the updated JSON. One of Redis's advantages is that it natively understands various data structures. Out of the box, it supports lists, sets, hashes, and sorted sets. Each one comes with operations built specifically for it, so you can change the data in place without pulling the whole thing back to your app. Let's say you're building a real-time gaming leaderboard. In a traditional database, you'd have to sort all the rows by score from highest to lowest on every single request.

[00:02:32]Doing that on millions of rows for every page refresh is just really slow. In Redis, you use a sorted set. Under the hood, a sorted set is implemented using a hash table and a skip list. When you insert a player's score, Redis does the sorting right then in memory. When you need the top 10 players, there is no sorting left to do.

[00:02:51]You aren't just storing data. You are shifting the computation from your application layer directly into the memory layer. Now, this brings us to one of the most counterintuitive aspects of Redis.

[00:03:01]How does it handle thousands of concurrent client connections? If you have 10,000 users hitting your API, and that API is hitting Redis, you might assume Redis spins up thousands of threads to handle them, just like a traditional web server would, but it doesn't. It's single-threaded. When people hear this, they assume it must be slow. How can a single thread process 100,000 requests per second? To understand this, we have to look at what actually makes a multi-threaded application slow. When multiple threads try to access the same piece of memory, you have to use locks or mutexes to prevent data corruption. Thread A locks the data, thread B waits. The CPU wastes valuable cycles just switching between threads and managing who has access to what. Redis avoids this entirely because all the data is in RAM, reading or writing a value takes almost zero time.

[00:03:48]The real bottleneck is the network, waiting for the data packets to travel from the client to the server. So, Redis uses a technique called IO multiplexing.

[00:03:57]Specifically, it uses system calls like epoll on Linux. Instead of assigning one thread to wait for one network connection, a single thread monitors thousands of connections simultaneously.

[00:04:07]When a network socket has a command ready to execute, Redis takes that command, puts it in a queue, and executes it. Because it's single-threaded, commands are executed strictly one after the other. This guarantees atomic operations. You never have to worry about race conditions. If two users try to decrement an inventory counter at the exact same millisecond, Redis guarantees one will execute fully before the other begins. There is no need for locks.

[00:04:32]One thing worth mentioning is that modern versions of Redis use additional threads, but only for parsing network stuff.

[00:04:38]The actual execution of commands, the part that touches the data, remains strictly single-threaded to preserve this lock-free speed. So, we have an incredibly fast single-threaded execution loop running entirely in RAM.

[00:04:51]But, RAM is volatile. If the server loses power, the RAM is cleared, so it means that your data is gone. If you are using Redis purely as a temporary cache, maybe you don't care. But, if you are using it to store user sessions or shopping carts, data loss can be a problem.

[00:05:06]This is where the hidden complexity of Redis persistence comes in.

[00:05:09]Redis solves this problem using two completely different mechanisms, RDB and AOF. RDB stands for Redis database. It takes point-in-time snapshots of your entire data set and saves them to disk.

[00:05:22]But, if Redis is single-threaded and writing 10 GB of data to an SSD takes several seconds, wouldn't taking a snapshot freeze the entire database and block all incoming requests?

[00:05:32]It would if Redis didn't use a brilliant operating system trick. When it's time to take a snapshot, Redis asks the Linux kernel to execute a fork system call.

[00:05:41]This creates a child process that is an exact duplicate of the Redis parent process.

[00:05:46]At the moment of the fork, both the parent and the child point to the exact same memory addresses.

[00:05:51]The child process then begins slowly writing that memory to disk.

[00:05:55]But, what if the parent process receives a write command and needs to modify that memory while the child is still saving it? The kernel handles this using a mechanism called copy-on-write. If the parent tries to modify a page of memory, the OS intercepts it, creates a duplicate of just that specific page, and lets the parent modify the new one.

[00:06:13]The child process remains completely undisturbed, seeing the memory exactly as it was at the exact millisecond the fork occurred. The main thread never blocks, and the snapshot gets safely saved to disk. The second persistence method is AOF, or append-only file.

[00:06:28]While RDB takes snapshots every few minutes, AOF is a continuous log. Every time a write command is executed, like set key value, Redis appends that exact command to a file on disk. If the server crashes, Redis can perfectly reconstruct the data set by reading the AOF file from top to bottom and replaying every single command. In production, these two methods are often used together. RDB gives you fast restarts and compact backups, while AOF guarantees you won't lose the last few minutes of data if the power goes out. When you put all these pieces together, the in-memory architecture, the rich data structures, the lock-free single-threaded event loop, and the background persistence mechanisms, you realize why Redis is so ubiquitous. It's not just a cache, it's a highly optimized system for solving distributed architecture problems. If you need to enforce API rate limiting, use Redis string with an expiration timer. If you need to pass messages between microservices, use Redis pub/sub or Redis streams.

[00:07:25]And if you need to prevent users from booking the same seat simultaneously, use Redis atomic transaction. Redis forces you to think differently about how you store data. Instead of dumping everything into rigid relational tables and relying on slow disk reads, it gives you low-level data structures optimized for the speed of RAM wrapped in a network interface. So, the next time you type docker run Redis, you aren't just spinning up a temporary bucket for cache misses, you're spinning up one of the most elegantly engineered pieces of software in the modern stack. If you enjoyed this video, drop a like and subscribe, and tell me in the comments what you want me to break down next.