Redis
The in-memory data-structures server that became infrastructure — cache, queue, rate limiter, session store, and leaderboard in one, with durability caveats to respect.
What is Redis?
Redis is an in-memory data store, but calling it a “cache” undersells it — it’s a data-structures server: strings, hashes, sorted sets, streams, bitmaps, HyperLogLogs, pub/sub, geospatial indexes, and Lua scripting, all operating at microsecond latency because everything lives in RAM. That versatility is why Redis shows up as cache, rate limiter, session store, job queue, leaderboard, and real-time pub/sub bus — often several of those at once in the same deployment. (Note the 2024 licensing shift and the community Valkey fork; managed offerings now span both.)
Why the data structures matter
The structures aren’t trivia — they’re what let Redis replace bespoke code. Sorted sets make leaderboards and rate limiters trivial; INCR with expiry is a rate limiter; streams provide a lightweight queue with consumer groups; pub/sub powers real-time fan-out. Reaching for the right structure turns problems that would need a database table and application logic into a single atomic Redis command. This is the practitioner’s edge: knowing that the thing you’re about to build with a table and a cron job is one sorted-set operation away.
The durability caveat you must respect
Redis is memory-first, and that shapes everything. Persistence options exist — RDB (periodic snapshots) and AOF (append-only log of writes) — but they’re a spectrum of durability-vs-performance, not a guarantee of a traditional database. Under memory pressure Redis evicts keys per your policy; on failover, unpersisted writes can vanish. So the rule: Redis is superb as a fast layer in front of a source of truth, dangerous as the only copy of data you can’t lose. Treating it as a durable primary database is the classic incident. Cluster mode shards across nodes for scale; replication provides read scaling and failover.
What people get wrong
- Redis as the source of truth for data that can’t be lost — eviction and failover will eventually prove why it isn’t.
- String-only usage — ignoring the data structures that would replace whole subsystems.
- No eviction/memory policy — an unbounded Redis eventually OOMs or evicts your hot data unpredictably.
Primary source: Redis documentation
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.