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

Backlinks