SysPad › Lessons › database lessons › Redis (self-managed)

How Redis (self-managed) works

Self-managed Redis / Valkey in-memory data store running on your own infrastructure (EC2, Kubernetes, or bare metal). Use it for caching, sessions, pub/sub, and rate limiting. Mode picks which workload is simulated: cache (hits absorbed, misses forwarded) or pub/sub (each publish fanned out to every subscriber). For the AWS-managed equivalent, use Amazon ElastiCache.

Your database is fast, but not "answer in a fraction of a millisecond, millions of times a second" fast. Redis is: it keeps data in memory and is the go-to layer for caches, sessions, rate limiters, and leaderboards. Run it yourself and you trade managed convenience for full control, as long as you respect what "in memory" means.

What you will learn

Why is an in-memory store so much faster than a disk database?
Why is a single Redis node single-threaded, and how do you scale past it?
What is Redis actually good at beyond plain caching?
What does "in memory" mean for durability, and what is the catch of self-managing?

In-memory means sub-millisecond

Redis (and its open-source fork Valkey) is an in-memory key-value store. Because data lives in RAM, not on disk, typical operations finish in a fraction of a millisecond, often 10 to 100 times faster than reading from a relational database.

Single-threaded, then clustered

A Redis node executes commands single-threaded, one at a time. That sounds limiting but each command is so fast that one node handles hundreds of thousands of ops per second, and it sidesteps locking complexity. To go further you cluster: sharding keys across nodes scales throughput roughly linearly.

⚓ Read-heavy apps caching DB results, session stores, API rate limiters, real-time leaderboards, and lightweight pub/sub and queues.

More than a cache

As a cache, Redis serves hot data and lets misses fall through to the database, cutting load dramatically. But its data structures make it more: counters and sorted sets power rate limiters and leaderboards, lists make simple queues, and pub/sub and streams move events.

Durability, and the self-managed catch

Memory-first does not mean data-loss-guaranteed. RDB snapshots the dataset periodically and AOF logs every write for stronger durability, you choose the balance of safety versus overhead. Replicas add high availability.

Flashcards

Why is Redis sub-millisecond?: Data lives in RAM, not on disk, so reads/writes avoid disk latency entirely.
Redis is single-threaded per node, so how do you scale throughput?: Cluster it: shard keys across multiple nodes, which scales throughput roughly linearly.
Name uses for Redis beyond caching.: Rate limiting (counters), leaderboards (sorted sets), sessions, queues (lists), and pub/sub.
How can Redis persist data despite being in-memory?: RDB periodic snapshots and AOF per-write logging; replicas add HA.
Self-managed Redis vs ElastiCache/MemoryDB?: Self-managed = full control, you run failover/backups/scaling. ElastiCache (cache) and MemoryDB (durable) are the AWS-managed equivalents.

Sources

Open the SysPad canvas · Official Redis (self-managed) documentation