Most engineers who use Redis can set a key and read it back, and would struggle to say why a hash with 100 fields costs a tenth of what the same hash costs with 200, what the server is doing during the two seconds it answered nothing, or why a successful write can disappear thirty milliseconds later with every acknowledgement in place. Those gaps have costs: a cache that evicts the wrong half of the keyspace under pressure, a background save that doubles the memory of a machine chosen to fit one copy, a lock that two holders believe they own, and a failover that loses the writes that mattered most because they were the most recent.

This course takes the server apart. It starts with the event loop and the one design decision the rest of Redis follows from, then establishes where that decision no longer holds: the I/O threads that read and write sockets, the background threads that close files and release memory, and the fork that does the saving. Then the wire: RESP in both versions, why pipelining changes throughput by an order of magnitude without changing a single command, and what the keyspace actually is below the dictionary interface.

The second section is the part that pays for itself fastest. Five data types are implemented by eight encodings, each with a conversion threshold set in the configuration file, and nearly every memory surprise in a Redis deployment is an encoding conversion nobody knew existed. Strings and the three string encodings, hashes and lists on listpacks, sorted sets as a skiplist beside a hashtable, the probabilistic types with their fixed error bounds, and streams with the consumer-group bookkeeping that makes them the only Redis type that remembers who read what.

Memory, persistence and replication then get the treatment they need. Where the memory went, which is never the sum of the values: allocator bins, the overhead per key, fragmentation and the active defragmenter. Expiration as two mechanisms that behave differently under load, and eviction as an approximation of LRU that samples rather than sorts. Persistence as one fork with two output formats, with the copy-on-write arithmetic that decides whether a save is survivable. Replication as an asynchronous stream over a circular backlog, with the partial resynchronisation that avoids a full transfer and the conditions under which it cannot.

Failover is treated as a consistency question rather than an availability feature, because that is what it is. Sentinel's quorum and the split-brain window it leaves open, Cluster's slot map and the resharding protocol that moves slots without stopping writes, and then the limits honestly: what WAIT does and does not promise, how many writes a failover can lose and why, and the two settings that trade availability for a smaller loss window.

The last third is correct use and operations. Transactions and optimistic locking with WATCH, Lua scripts and the Functions API with the atomicity they buy and the latency they can hold, distributed locks with the Redlock argument and its rebuttal laid out so you can decide rather than cite, and the caching patterns around stampede and hot keys. Then operations: the sources of latency in order of how often they are the answer, the slowlog and the latency monitor, capacity planning from measured figures, and the failures that recur in every installation with their signatures.

Every section names the configuration directives it discusses together with their defaults, works the arithmetic with real numbers, and prefers the failure case to the happy path. By the end you will be able to explain where a gigabyte went, choose an eviction policy from the shape of the keyspace, size a replication backlog so a restart does not trigger a full sync, read an incident from four commands, and say exactly how much data a failover is allowed to lose.