Learning Redis - History, Concepts & Why Choose Redis

#Introduction

Episode 0 already made sure your environment is ready. Now it's time to understand why Redis exists and why you should learn it. Episode 1 answers three big questions: where Redis comes from, what Redis actually is, and why it deserves to be chosen over other alternatives.

Many people use Redis only because of tutorials, yet understanding its historical context and concepts is far more valuable. By knowing the problem it solves, you'll find it easier to decide when to use Redis, when not to, and how to position it within your application architecture. Let's start at the beginning of the story.

#Redis History

#Born from the Hands of antirez

Redis was created by Salvatore Sanfilippo, known to the community as antirez, in 2009 in Italy. It didn't start as a big project: antirez developed Redis for a real-time analytics project he was working on, and needed a database far faster than the solutions available at the time.

Redis's speed and design simplicity caught the open-source community's attention very quickly. In 2010, VMware began sponsoring its development, followed by Pivotal in 2013, and finally the company Redis Labs (now Redis Ltd) was founded in 2015 as the project's commercial home.

#License Change and the Valkey Fork

March 2024 was a major turning point. Redis Ltd changed Redis's license to SSPL and RSALv2 — no longer permissive BSD. As a result, the Linux Foundation launched a fork named Valkey, which is a direct continuation of the last BSD-licensed Redis code.

redis-cli INFO server | grep redis_version

redis-cli INFO server | grep redis_version shows your Redis version. If you run Redis in Docker with the official image, the version is Redis 7.x. You should know that many cloud providers and distros now offer Valkey as a drop-in replacement — most of the commands we'll learn in this series are identical on both.

#Redis Fundamentals

#In-Memory Data Structure Store

Redis is an in-memory data structure store: all data lives in RAM, not on disk. Data access has sub-millisecond latency (typically under 1ms), far faster than disk-based databases that must read from physical storage.

L1/L2 cache (nanoseconds)
  → Redis (RAM, sub-millisecond)
      → disk-based SQL/NoSQL (milliseconds - tens of milliseconds)
          → Cold storage (seconds)

Precisely because data lives in RAM, Redis is extremely fast — but that is also why memory is limited and why persistence (episode 2) becomes an important architectural decision.

#More Than Just Key-Value

The term "key-value store" is often misleading. Redis is not merely a simple SET key value. It supports rich data structures:

• Strings for caching and counters.
• Lists for queues and timelines.
• Hashes for objects and sessions.
• Sets and Sorted Sets for tags, unique visitors, and leaderboards.
• Streams for event streaming and message brokering.
• Bitmaps, geospatial, and HyperLogLog for special-purpose use cases.

All these structures operate server-side, which means operations like INCR or SINTER run atomically without having to bring data to the application. This is what makes Redis used in almost every large-scale application.

#Why Choose Redis

#Extreme Performance

Redis is capable of running 100,000+ operations per second on a single instance, thanks to its single-threaded design that avoids locking conflicts. This makes Redis the top choice for the most performance-critical paths of an application.

#Versatile Use Cases

A single Redis server can serve many roles at once:

• Cache for database and API acceleration.
• Session store for login state in web applications.
• Message broker for job queues and pub/sub.
• Rate limiter to protect APIs from abuse.
• Leaderboard and real-time analytics.
• Distributed lock for coordination across application instances.

Because one tool can do all of this, teams don't need to operate five separate infrastructures. That is a big reason why Redis dominates.

#Redis vs Alternatives

#Comparison Table

To position Redis correctly, compare it with its competitors:

#When to Use What

Memcached is only suitable for pure KV caching without data structures and without persistence. KeyDB and DragonflyDB are interesting if you need more throughput than a single CPU core can provide, thanks to their multi-threaded design. Valkey is the choice if you want open-source licensing certainty with the exact same Redis experience.

For the majority of needs — the largest community support, the most complete documentation, and the fullest feature set such as Redis Modules and Streams — Redis remains the safest choice, with Valkey as a drop-in alternative worth monitoring.

#Summary

Episode 1 gave you context: Redis was born in 2009 from the hands of Salvatore Sanfilippo, changed its license in 2024 giving rise to the Valkey fork, and is now the most popular in-memory data structure store with sub-millisecond latency and 100,000+ operations per second.

Key takeaways:

• Redis was created by antirez in 2009 and grew into a project with commercial sponsorship.
• The 2024 license change to SSPL/RSALv2 spawned Valkey as an open-source fork.
• Redis stores data in RAM, yielding latency below 1 millisecond.
• Redis is more than key-value: there are strings, lists, hashes, sets, sorted sets, and streams.
• Single-threaded performance can reach 100,000+ operations per second.
• Redis vs Memcached/KeyDB/DragonflyDB: choose based on features, license, and throughput.

In the next episode, episode 2, we will cover internal architecture and persistence model — how the single-threaded event loop works with I/O multiplexing, why Redis stays fast despite being single-threaded, and the differences between RDB, AOF, and their combination for storing data from RAM to disk. This is the architectural foundation that will accompany the entire series.