What Is Redis? Not Just a Cache, but an In-Memory Data Structure Server

Most people first meet Redis as a “cache” — throw database query results in, grab them next time. That’s right, but it sells it short. Redis is at heart an in-memory data structure server, and caching is only the most famous of its many uses. This post makes clear what it actually is, why it’s so fast, and when to use it and when not to.

Not just a cache: its values are “data structures”

The most fundamental difference between Redis and a pure key-value cache like memcached is what the value is. A traditional cache’s value is a blob of string opaque to the server; to change one field you read the whole thing back to the application, change it, and write the whole thing back. Redis is different: its value can be a List, Hash, Set or Sorted Set, and the server natively supports operations on those structures — you can tell it directly to push an element, add to a member’s score, fetch the top ten, all completed atomically on the server side:

This is the most important conceptual upgrade in getting to know Redis: it isn't "a cache that stores strings" but "data structures you can operate remotely". A traditional cache moves the whole value in and out to change one field; Redis lets you push the computation (sorting, counting, set operations, range queries) right next to the data and complete it atomically on the server. Leaderboards, rate limiting, queues, deduplicated counts — the things Redis does in a few commands all come down to this difference

Put another way: what Redis gives you is a shared, extremely fast, remotely operable toolbox of data structures. Several services can score the same Sorted Set at once, deduplicate against the same Set, send and receive tasks on the same List — the data structures you used to have only inside a single program become something the whole distributed system can share. That’s its real value; caching is just one slot in the box.

Why it’s so fast

Redis routinely does hundreds of thousands of QPS on one machine at microsecond latency. The speed isn’t one piece of magic but three things stacked together:

Three pillars, none optional: memory removes the slowest thing, random disk I/O; the single thread buys the simplicity of "no locks, no races, predictable behaviour" (which is also why one command that runs too long drags the whole server down — the next post's topic); epoll I/O multiplexing lets one thread attend to tens of thousands of connections at once. Add memory-saving encodings tailored to small values, and you get that outrageous performance number

An often-overlooked point here: the single thread isn’t a weakness; it’s a deliberate design trade. It trades “do one thing at a time” for simplicity and predictability across the whole system — no locks, no race conditions, atomic commands by construction. The price: one slow command blocks everyone (because everyone is in the same queue). That double edge is the star of the next post.

When to use it, and when not to

Once you treat Redis as a “data structure toolbox”, the fit is easy to judge:

Great fit: caching, session storage, leaderboards (ZSet), counters and rate limiting, lightweight task queues (List / Stream), deduplication and cardinality counts (Set / HyperLogLog), real-time rankings, distributed locks, pub/sub notifications. The common thread — hot, small, needs to be fast, and maps onto some data structure.
Don’t force it: as the primary database for large volumes of cold data (memory is expensive), for very large single values, for complex multi-table joins and relational queries, or where you need financial-grade durability and transaction guarantees. Those belong to relational databases or purpose-built systems; Redis isn’t there to replace them.

In one sentence: Redis takes the small slice that’s “hot and needs real-time operations”, carrying the hottest data and computation; the cold, the large and the strongly consistent go to the database behind it.

Hands on: feel “operating structures” rather than “storing blobs”

We’re engineers after all; connecting with redis-cli and playing is the most tangible — the point isn’t how many commands there are, but that what you’re operating on is the structure itself:

redis-cli                     # connect (default 127.0.0.1:6379; -h/-p/-a for host/port/password)
> SET user:1 "Aidan"          # String
> LPUSH feed p3 p2 p1         # List: push onto the head directly, no read-modify-write of the whole thing
> HSET user:1 age 30 city TP  # Hash: change just one field
> INFO server                 # version, run mode, connection count
> DBSIZE                      # how many keys right now

Look at that LPUSH — you didn’t “read the whole list, edit it, write it back”; you issued an operation directly on the structure. That’s the fundamental difference between an “in-memory data structure server” and memcached storing a blob, and it’s the foundation for every post that follows.

Reflections

Treat Redis as “data structures” rather than “a cache” and you’ll use it completely differently

I’ve seen many people use Redis with only two moves, GET/SET, forever — treating it as a slightly faster memcached. That wastes ninety percent of its capability. The real turning point for me was a real-time leaderboard: I’d planned to store scores in the DB and ORDER BY them back on every query, and the load test collapsed on the spot. Switching to one Sorted Set — ZADD to score, ZREVRANGE to fetch the board — halved the code and dropped latency from hundreds of milliseconds to single digits. That’s when I truly understood: Redis’s power isn’t in “caching”; it’s in turning data structures into a shared, remotely operable service. My angle on requirements changed from then on — not “does this need a cache” but “which data structure does this map to, and can the computation be pushed to the Redis side”.

Speed has a price, and the price sets its boundaries

Redis is outrageously fast, but there’s no free lunch in engineering; every “fast” corresponds to a “can’t”. Memory is fast, but memory is expensive and finite — so it suits hot data, not a big warehouse. A single thread is simple and lock-free, but one slow command freezes the whole room — so you have to stay wary of KEYS and O(N) operations on large collections. When I evaluate whether to use Redis now, I think not just “can it do this” but “where does its cost land, and can I bear it”. Understanding a tool’s trade-offs matters more than understanding its features — features decide what it can do; trade-offs decide when it bites you.

It’s the “hot data layer”, not a database replacement

One last idea I keep reminding teams of: Redis is the hot data layer, sitting between the application and the database, carrying the hottest slice that most needs real-time operations — not a replacement for the “source of truth” behind it. Get that positioning right and many architecture problems dissolve on their own: the authoritative copy of the data still lives in the database, what’s in Redis is a rebuildable acceleration layer, and the anxiety of “if Redis dies, is the data gone” downgrades from “disaster” to “a slow trip to the origin for a while”. Knowing who is the truth and who is the accelerator is the first step in using any cache layer well — and the main thread we’ll keep returning to in the later posts on persistence and on the cluster.