Redis is an open-source, in-memory data store. Let's break that down.

"In-memory" means Redis keeps the entire dataset in RAM, or main memory. This makes it incredibly fast. Accessing data from RAM is orders of magnitude faster than reading from a traditional disk-based database. This speed is Redis's main claim to fame.

"Data store" means it's a place to keep information. Specifically, Redis is a key-value store. You store a piece of data (the "value") and assign it a unique identifier (the "key"). To retrieve the data, you just provide its key. Think of it like a giant dictionary or hash map where you look up definitions (values) using words (keys).

Because of its speed and simplicity, Redis is extremely versatile. It's most famous for caching, where it stores frequently accessed data to speed up applications. But it's also used as a primary database, a message broker to pass information between different parts of a system, and for real-time applications like leaderboards and session management.

The basic key-value concept is simple, but Redis enhances it by supporting complex data structures as values. You aren't limited to just storing simple text. This is a huge advantage, as it lets you work with data in more natural ways and offload complex operations to Redis itself.

Strings are the most basic Redis data type. They can hold any kind of data, such as text, serialized JSON, or even a JPEG image, up to 512 megabytes.

Lists are collections of strings sorted in the order they were added. You can add elements to the head or the tail of a list, making them ideal for implementing queues or stacks.

Hashes are perfect for storing objects. They are maps between string fields and string values. Instead of serializing an object into a single string, you can store its fields in a hash. This allows you to get or update individual fields without fetching the entire object.

Sets are unordered collections of unique strings. You can add, remove, and test for the existence of members in constant time. They are great for tracking unique items, like the tags on a blog post or the unique visitors to a website.

Sorted Sets are similar to Sets but with a crucial difference: every member is associated with a score (a floating-point number). The members are always sorted by this score. This makes Sorted Sets a perfect fit for building things like leaderboards or anything that requires ordered elements.

You might hear that Redis is single-threaded and think that's a limitation. In modern computing, we're used to the idea that more threads mean more power. But for Redis, it's a deliberate design choice that provides a key benefit: atomicity.

Because Redis processes commands one at a time, each command is atomic. It will run to completion before the next command begins. You never have to worry about two clients modifying the same data at the exact same time and creating a corrupted state. This simplifies application logic immensely.

So how does it handle thousands of connections at once? Redis uses a clever technique called non-blocking I/O. It doesn't wait around for slow operations like network communication. It starts an operation and tells the operating system to notify it when it's done. While it waits, it's free to process other commands. This model allows a single thread to handle many concurrent connections with very high throughput.

Since Redis stores data in memory, what happens if the server crashes or restarts? Does all the data disappear? Not necessarily. Redis provides two primary methods for persisting data to disk, allowing you to balance performance and durability.

Snapshotting (RDB) This method takes point-in-time snapshots of your entire dataset. You can configure Redis to save a snapshot automatically after a certain number of writes or after a certain amount of time has passed (e.g., save if at least 10 keys have changed in the last 5 minutes). RDB files are compact and fast to load when restarting, which is great for disaster recovery.

The downside is potential data loss. If Redis crashes between snapshots, all the changes since the last successful snapshot are lost.

Append-Only File (AOF) The AOF method provides much better durability. Instead of saving the dataset all at once, Redis logs every single write operation to a file. When Redis restarts, it simply replays the commands from the AOF to rebuild the state.

You can configure how often Redis writes to the file. Writing on every command is the safest but can impact performance. Writing every second is a common compromise, limiting potential data loss to just one second.

AOF files are typically larger than RDB files, and replaying them on restart can be slower. For maximum safety, it's common to use both persistence methods at the same time.

Let's check your understanding of these core Redis concepts.

With this foundation, you now understand what Redis is, the data structures it offers, and how it manages to be both fast and durable. These concepts are the building blocks for using Redis effectively in complex systems.