Tech Notes

Redis

4 min read

What Redis Is

Redis is an in-memory, single-threaded data structure store optimized for speed and simplicity.

Summary

Redis trades durability for speed. Think microsecond reads, not disk-level guarantees.

Analogy: Redis is like a shared whiteboard in RAM — extremely fast to read/write, but not meant for permanent records.

Why Redis Is Powerful

  • versatile: cache, lock, queue, leaderboard, rate limiter, pub/sub
  • simple mental model: keys + data structures
  • predictable behavior (no query planners, no magic)

Important

Going deep on Redis beats shallow knowledge of many systems.

Redis Fundamentals

Core properties

  • in-memory
  • single-threaded (per node)
  • extremely fast
  • weaker durability (by design)

Durability options:

  • AOF (append-only file)
  • managed variants (e.g. AWS MemoryDB)

Warning

Redis is not a primary database replacement.

Supported data structures

  • strings
  • hashes (objects)
  • lists
  • sets
  • sorted sets (priority queues)
  • bloom filters (false positives allowed)
  • geospatial indexes
  • time series
  • streams

Summary

Redis features map closely to common coding data structures.

Redis Logical Model

  • key-value store
  • keys are strings
  • values are Redis data structures
  • every object is accessed via a key

Important

Key design = data layout + scalability strategy.

Commands (Mental Model)

Redis uses a simple text-based protocol.

Examples:

  • SET / GET / INCR
  • SADD / SCARD / SISMEMBER
  • ZADD / ZRANGE
  • XADD (streams)

Tip

Redis commands read like method names on data structures.

Infrastructure Configurations

Single node

  • fastest
  • no fault tolerance

Primary + replica

  • high availability
  • read scaling

Redis cluster

  • horizontal scaling
  • keys mapped to hash slots
  • clients cache slot → node mapping

Analogy: hash slots are like a phone directory for keys.

Important

Redis expects most operations to touch one node only.

Performance Characteristics

  • ~100k+ writes/sec
  • microsecond read latency
  • many small requests are acceptable

Summary

Redis makes patterns viable that would be terrible in SQL.

Redis as a Cache (Most Common)

Pattern:

  • key → cached object
  • value → JSON or hash
  • TTL on keys

Guarantees:

  • expired keys are never returned
  • TTL helps control memory

Warning

Redis does NOT solve the hot-key problem by itself.

Redis as a Distributed Lock

Use cases:

  • ticket booking
  • ride matching
  • mutual exclusion

Simple lock:

  • INCR lock_key
  • value == 1 → lock acquired
  • TTL prevents deadlocks
  • DEL on release

Important

Prefer database consistency over distributed locks when possible.

Advanced:

  • Redlock
  • fencing tokens

Redis for Leaderboards

Uses sorted sets.

Example:

  • score = likes
  • member = postId
  • query top K efficiently

Operations:

  • add/update score
  • trim low-ranked items

Summary

Sorted sets = fast ranking + real-time updates.

Redis for Rate Limiting

Fixed window

  • INCR counter
  • EXPIRE key
  • block if count > N

Sliding window

  • sorted set of timestamps
  • remove old entries
  • count remaining
  • use Lua for atomicity

Important

Lua scripts keep multi-step logic atomic in Redis.

Built-in geospatial indexes.

Concept:

  • uses geohashes internally
  • coarse filter + precise distance check

Complexity:

  • O(N + log M)

Summary

Redis geo queries are fast but approximate-first, precise-second.

Redis for Event Sourcing (Streams)

Streams:

  • append-only log
  • similar to Kafka topics

Consumer groups:

  • track processed entries
  • support reprocessing on failure

Use case:

  • work queues
  • retryable jobs

Important

Redis Streams give durability that Pub/Sub lacks.

Redis for Pub/Sub

Characteristics:

  • real-time fan-out
  • ephemeral
  • at-most-once delivery
  • messages not persisted

Commands:

  • SPUBLISH
  • SSUBSCRIBE

Warning

Offline consumers miss messages permanently.

Use when:

  • chat
  • live notifications
  • real-time updates

Avoid when:

  • durability required
  • replay needed

Hot Key Problem (Classic Pitfall)

Scenario:

  • one key gets massive traffic
  • one node overloaded
  • cluster underutilized

Solutions:

  • client-side caching
  • key replication + random reads
  • read replicas
  • request sharding

Summary

Hot keys are a design problem, not a Redis bug.

Key Design Tips

  • call out hot-key risk early
  • justify Redis vs DB vs Kafka
  • explain TTL, durability trade-offs
  • emphasize key design

Final Takeaway

Summary

Redis is a fast, simple, in-memory data structure store. Its power in system design comes from versatility + predictability. If you understand keys, data structures, and trade-offs, you can design many systems convincingly.

Graph View