We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Database Types & Storage
An in-memory data store used as a cache, message broker, and database. Blazing fast because everything lives in RAM.
In short
Redis is an open source in-memory data store that keeps all of its data in RAM, which lets it answer reads and writes in well under a millisecond. It is used as a cache, a message broker, and sometimes a primary database, and it supports rich data types like strings, hashes, lists, sorted sets, and streams rather than just plain key-value pairs.
In short
Redis is an open source in-memory data store that keeps all of its data in RAM, which lets it answer reads and writes in well under a millisecond. It is used as a cache, a message broker, and sometimes a primary database, and it supports rich data types like strings, hashes, lists, sorted sets, and streams rather than just plain key-value pairs.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Redis across a run of lessons, not one page. These 4 alone are about 101 minutes of step-by-step reading, every one with a quiz.
The same small GET measured 0.3 ms at worst on an idle server and 59.1 ms while one other client ran KEYS. Reading one field cost 0.934 ms as a blob and 0.040 ms as a hash.
A refresh-ahead cache reloads hot entries before their TTL ends, so readers stop waiting. A Redis lab measures the factor, the cost and stale-while-revalidate.
A shared cache is a network service, so how you call it matters far more than which product you picked.
How systems take a consistent snapshot without stopping writes. Compares four techniques, including Redis fork with copy-on-write and Postgres MVCC.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Redis Cachepay once,
yours for life
Redis stands for Remote Dictionary Server. At its core it is a single key-value store, but the values are not limited to strings. A value can be a hash (a small map of fields), a list, a set, a sorted set ordered by a score, a bitmap, a HyperLogLog, a stream, or a geospatial index. This is why Redis is often called a data structures server instead of just a cache.
Everything lives in memory. A lookup does not touch a disk, walk a B-tree, or cross a network of storage nodes, so a typical operation finishes in a few microseconds on the server and a fraction of a millisecond once you add network round-trip. A single Redis node can serve well over 100,000 operations per second on commodity hardware.
Redis is single-threaded for command execution. One command runs to completion before the next starts, so individual operations are atomic with no locks to manage. Modern versions use extra threads for network I/O, but the command processing model stays simple and predictable.
Because RAM is volatile, Redis offers two ways to survive a restart. RDB takes point-in-time snapshots of the whole dataset on a schedule, which is compact and fast to load but can lose the writes since the last snapshot. AOF (append-only file) logs every write command and replays it on startup, which loses less data but produces larger files. Many production setups run both.
Single-key atomicity covers simple cases, but Redis also gives you MULTI/EXEC transactions and Lua scripts that run server-side as one atomic block. Scripts are the common way to do read-then-write logic, like a rate limiter or a leaderboard update, without a race between two clients.
For scale and availability, Redis replicates from a primary to one or more read replicas asynchronously. Redis Sentinel watches the primary and promotes a replica if it dies. Redis Cluster goes further by sharding the keyspace across 16,384 hash slots spread over multiple primaries, so the dataset can outgrow a single machine's memory.
Keys can carry a TTL. Set a key to expire in 60 seconds and Redis removes it for you, which is how it behaves as a cache. When memory fills up, an eviction policy such as allkeys-lru or volatile-ttl decides what to drop.
Reach for Redis when you need very low latency and the access pattern is key-based: caching database query results or rendered pages, session storage, rate limiting, real-time leaderboards, counters, and pub/sub or stream-based message passing. It shines as a layer in front of a slower system of record like PostgreSQL or DynamoDB.
The main constraint is that your working set has to fit in RAM, and RAM is far more expensive per gigabyte than disk. A 100 GB dataset that costs little on disk can be costly to hold entirely in memory, so Redis is usually for hot data, not the full archive.
Durability is the other trade-off. Even with AOF set to fsync every second, a crash can lose up to a second of writes, and asynchronous replication means a failover can lose recently acknowledged writes. For data you cannot afford to lose, keep the authoritative copy in a durable database and treat Redis as an accelerator. Also avoid commands like KEYS in production, because scanning the whole keyspace on a single-threaded server blocks every other client.
Picture a news site that shows article view counts. Every page load would otherwise issue an UPDATE and a SELECT against the main database, which buckles under a traffic spike. Instead, each view runs INCR article:1234:views in Redis, an atomic in-memory increment that takes microseconds. A background job flushes the counts to PostgreSQL every minute.
The same site caches each rendered article: SET article:1234:html with a 5 minute TTL. The web server checks Redis first, and only on a miss does it render from the database and store the result. With a good hit rate the database sees a tiny fraction of the original load, and readers get pages served straight from memory.
Twitter (X)
Used Redis to serve timelines, storing each user's home feed as a list of tweet IDs in memory for fast fan-out reads.
GitHub
Runs Redis for background job queues (via Resque) and for caching, keeping web request latency low.
Stack Overflow
Uses a small number of Redis servers as a shared cache layer across the whole site, handling billions of operations a day.
AWS ElastiCache and Amazon MemoryDB
Offer fully managed Redis-compatible services so teams get clustering, failover, and backups without running the servers themselves.
It is both. Most teams use it as a cache in front of a durable database, but with AOF persistence and replication enabled it can serve as a primary store for data that can tolerate a small risk of loss on failover.
Not if you configure persistence. RDB snapshots and AOF logging let Redis rebuild its dataset on startup. With AOF you might lose up to about a second of writes; with snapshots alone you lose everything since the last snapshot.
All data lives in RAM, so reads and writes never wait on disk. Command execution is single-threaded, which removes lock contention, and the protocol and data structures are tuned so most operations finish in microseconds.
Memcached is a simpler in-memory cache that stores plain strings. Redis adds rich data types, persistence, replication, clustering, pub/sub, transactions, and Lua scripting, so it does much more than caching.
Redis Cluster shards keys across 16,384 hash slots spread over multiple primary nodes, so the combined memory of the cluster holds the data and clients are routed to the node owning each key.
Refresh-Ahead Cache: How It Works, Measured on Redis
A refresh-ahead cache reloads hot entries before their TTL ends, so readers stop waiting. A Redis lab measures the factor, the cost and stale-while-revalidate.
Distributed Caching with Redis and Memcached
A shared cache is a network service, so how you call it matters far more than which product you picked
Snapshotting
How systems take a consistent snapshot without stopping writes. Compares four techniques, including Redis fork with copy-on-write and Postgres MVCC.
Remote Cache
Measured against a real Redis on loopback, a hit costs 0.056 ms against 0.00004 for a local one. Work cheaper than that is made slower by caching it, and at 232 KB the parse was 94 percent of the hit
Key-Value Stores
How key-value databases work, how to design good keys, and how Redis, DynamoDB and etcd compare. Includes a diagram of a GET and SET operation.
Memcached
A simple, high-performance distributed memory caching system. Stores key-value pairs in RAM. Simpler than Redis but less feature-rich.
Caching
Storing frequently accessed data in a faster storage layer so you don't have to fetch it from the original (slower) source every time.
Rate Limiting
Controlling how many requests a client can make in a given time window. Protects your API from abuse and ensures fair usage.
Cache-Aside
A caching pattern where the application checks the cache first; on a miss, it fetches from the database and populates the cache. Also called lazy loading.
Document Database
A NoSQL database that stores data as flexible JSON-like documents. MongoDB and CouchDB let each document have a different structure.
Key-Value Store
The simplest NoSQL model: store data as key-value pairs. Blazing fast lookups by key. Redis, DynamoDB, and etcd are key-value stores.
This page explains the idea. The "Redis Cache" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Redis Cache lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Redis in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
