Redis Data Structures — Memory Eviction from Missing TTL

Every production system eventually hits a wall where a relational database is simply too slow for certain jobs. Not because SQL is bad — it's excellent — but because reading a user's session data, tallying votes in real time, or powering an autocomplete box requires sub-millisecond responses that a disk-backed database can't reliably provide. Redis lives in memory, and it was designed from day one around one idea: give developers a small set of powerful, purpose-built data structures so that the data's shape in storage matches the problem being solved.

The real problem Redis solves isn't just 'be fast.' Any cache can be fast. What makes Redis different is that its data structures let you do meaningful work on the server — increment a counter atomically, pop from a queue, compute the intersection of two sets — without pulling data into your application first. That server-side computation is what keeps your network traffic lean and your application logic clean.

By the end of this article you'll be able to look at a backend requirement — a leaderboard, a rate limiter, a social graph, a job queue — and immediately know which Redis data structure to reach for, why it's the right fit, and exactly how to implement it. You'll also know the gotchas that trip up engineers in their first month of production Redis use.

Strings — Redis's Swiss Army Knife (and Why It's More Than Just Text)

The String type is the most deceptively simple structure in Redis. It stores a single value — bytes, really — up to 512 MB. That value can be plain text, a serialized JSON blob, a binary image, or an integer. When the value is an integer, Redis lets you increment and decrement it atomically with INCR and DECR, which is the key insight most beginners miss.

Atomic means no race condition. If two servers both call INCR on the same key at the exact same millisecond, Redis executes them sequentially — you get 1, then 2, never 1 and 1. This makes Strings the go-to choice for rate limiting and counting: page views, API calls, login attempts.

The second superpower is the SET options. You can set a value with an expiry in one atomic command using SET key value EX seconds. This is how session tokens work in Redis — store the token as the key, the user ID as the value, and attach a TTL. No separate expiry-management logic needed.

When should you NOT use a String? When your data has multiple fields. Storing a JSON blob like '{"name":"Alice","age":30}' as a String forces you to deserialize the whole thing to update one field. That's exactly when you want a Hash.

-- Rate limiting: allow max 5 requests per user per 60 seconds
-- The key encodes both the user ID and the current time window

-- User 42 makes their first request in this window
SET rate_limit:user:42:window:1700000000 0 EX 60 NX
-- NX means 'only set if key does NOT exist'
-- EX 60 means expire in 60 seconds automatically
-- This gives us a self-cleaning counter

-- Now increment on each request
INCR rate_limit:user:42:window:1700000000
-- Returns: (integer) 1

INCR rate_limit:user:42:window:1700000000
-- Returns: (integer) 2

-- Check value before allowing the request
GET rate_limit:user:42:window:1700000000
-- Returns: "2"

-- Simulate hitting the limit
INCR rate_limit:user:42:window:1700000000
INCR rate_limit:user:42:window:1700000000
INCR rate_limit:user:42:window:1700000000
-- Returns: 5 — at this point your app logic blocks the request

-- Check remaining TTL (useful to tell user when they can retry)
TTL rate_limit:user:42:window:1700000000
-- Returns: (integer) 47  (13 seconds have passed)

Hashes and Lists — Modeling Objects and Building Queues

A Hash stores a map of field-value pairs under a single key. Think of it as a lightweight row in a database — one Redis key holds an entire user profile, product record, or config object. The power is granular updates: HSET user:99 email 'new@example.com' updates one field without touching the rest. No deserialization, no re-serialization, no wasted bandwidth.

Hashes are also memory-efficient. When a Hash has fewer than 128 fields and each value is under 64 bytes, Redis internally uses a compact encoding called a ziplist (listpack in newer versions) that's significantly smaller than storing each field as a separate String key. This is a free optimization you get just by modelling your data correctly.

Lists are an ordered sequence of strings, implemented as a doubly-linked list. Elements are pushed and popped from both ends in O(1) time. This makes Lists the natural fit for job queues: producers LPUSH work onto the left end, consumers BRPOP block-wait on the right end. The 'B' in BRPOP is crucial — it means blocking. The consumer sits idle, consuming zero CPU, until work arrives. No polling loop needed.

Lists also work as activity feeds. Push the latest N events with LPUSH and trim the list to a fixed length with LTRIM so it never grows unbounded. Combined, LPUSH and LTRIM on every write give you a capped, real-time feed in two commands.

-- ═══════════════════════════════
-- HASH: Storing a user profile
-- ═══════════════════════════════

-- Set multiple fields at once on first creation
HMSET user:99 \
  username    "alice_dev" \
  email       "alice@example.com" \
  plan        "pro" \
  login_count 0

-- Retrieve the whole profile
HGETALL user:99
-- Returns all fields and values as a flat list

-- Update just the plan without touching other fields
HSET user:99 plan "enterprise"

-- Atomically increment login_count (same as INCR but for Hash fields)
HINCRBY user:99 login_count 1
-- Returns: (integer) 1

-- Only fetch the two fields you actually need (saves bandwidth)
HMGET user:99 username plan
-- Returns: 1) "alice_dev"  2) "enterprise"


-- ═══════════════════════════════
-- LIST: Capped activity feed
-- ═══════════════════════════════

-- Push a new activity event for user 99 to the front of the list
LPUSH activity_feed:user:99 "logged_in"
LPUSH activity_feed:user:99 "viewed_dashboard"
LPUSH activity_feed:user:99 "exported_report"

-- Trim to the 10 most recent events — run this after every LPUSH
-- Index 0 = newest, index 9 = 10th newest, -1 = last element
LTRIM activity_feed:user:99 0 9

-- Read the 5 most recent events (newest first)
LRANGE activity_feed:user:99 0 4

-- Job queue: producer pushes, consumer blocks until work arrives
LPUSH email_queue "send_welcome:user:99"

-- On the worker process (blocks for up to 30 seconds)
BRPOP email_queue 30
-- Returns: 1) "email_queue"  2) "send_welcome:user:99"

Sets and Sorted Sets — Unique Collections and Real-Time Leaderboards

A Set is an unordered collection of unique strings. 'Unique' is the whole point — Redis enforces it automatically, so you never write deduplication logic yourself. The classic use cases are tagging systems, tracking which users have seen a notification, and social graph relationships like followers.

The feature that makes Sets genuinely powerful beyond simple uniqueness is set algebra: SINTER (intersection), SUNION (union), and SDIFF (difference) let you compute 'users who follow both Alice and Bob', 'all tags on either post', or 'users who bought A but not B' in a single command. Doing that computation in your application layer means pulling thousands of IDs over the network first. Doing it in Redis means only the result travels over the wire.

Sorted Sets (ZSets) are the crown jewel of Redis. Every member gets a floating-point score, and Redis keeps members ordered by that score at all times. Insertion, removal, and score updates are O(log N). Range queries — 'give me the top 10 players', 'give me everyone with a score between 1000 and 2000' — are also O(log N + result size). This is the data structure behind every real-time leaderboard you've ever used.

The score can represent anything orderable: timestamps (for time-sorted feeds), relevance scores (for search ranking), or geographic distances (for proximity search via geohashing). If you need ordered access by any numeric dimension, a Sorted Set is almost always the answer.

-- ═══════════════════════════════
-- SET: Social follow graph
-- ═══════════════════════════════

-- Store who user:alice follows
SADD following:alice  "bob" "carol" "dave"
SADD following:bob    "alice" "carol" "eve"

-- Store alice's followers
SADD followers:alice  "bob" "dave"

-- Who do alice AND bob both follow? (mutual interests)
SINTER following:alice following:bob
-- Returns: 1) "carol"  (both follow carol)

-- Everyone either alice or bob follows (combined feed sources)
SUNION following:alice following:bob

-- Mark notification 789 as seen by user alice (deduplication)
SADD seen_notifications:alice "789"

-- Has alice seen it? O(1) lookup
SISMEMBER seen_notifications:alice "789"
-- Returns: (integer) 1  (yes)

SISMEMBER seen_notifications:alice "999"
-- Returns: (integer) 0  (no)


-- ═══════════════════════════════
-- SORTED SET: Game leaderboard
-- ═══════════════════════════════

-- Add players with their scores
-- Score is the second argument, member is the third
ZADD game:leaderboard 4850 "player:alice"
ZADD game:leaderboard 6200 "player:bob"
ZADD game:leaderboard 5930 "player:carol"
ZADD game:leaderboard 7100 "player:dave"
ZADD game:leaderboard 3200 "player:eve"

-- Update alice's score after she beats a level (just ZADD again)
ZADD game:leaderboard 5500 "player:alice"

-- Top 3 players, highest score first (WITHSCORES shows the score too)
ZREVRANGE game:leaderboard 0 2 WITHSCORES

-- What rank is carol? (0-indexed, ZREVRANK = rank by descending score)
ZREVRANK game:leaderboard "player:carol"
-- Returns: (integer) 2  (3rd place, 0-indexed)

-- All players with scores between 5000 and 7000
ZRANGEBYSCORE game:leaderboard 5000 7000 WITHSCORES

-- How many players scored over 5000?
ZCOUNT game:leaderboard 5001 +inf
-- Returns: (integer) 3

Bitmaps and HyperLogLog — Efficient Counting and Boolean Operations

Bitmaps are not a distinct type — they're just Strings on which you can perform bit-level operations. Use SETBIT and GETBIT to manipulate individual bits. That gives you an incredibly memory-efficient way to store boolean flags: one user's daily sign-in for a year takes just 365 bits — about 46 bytes. Compare that to storing a String per day.

Bit operations like BITCOUNT, BITOP (AND, OR, XOR, NOT) let you compute retention, cohort analysis, and feature flags across millions of users in a single command. For example, BITOP AND daily:2026-03-01 daily:2026-03-02 shows users active on both days.

HyperLogLog is a probabilistic data structure for approximate cardinality counting with fixed memory. Each key takes ~12KB regardless of how many unique items you add. PFADD adds elements, PFCOUNT returns the approximate count (typical error 0.81%). It's perfect for counting unique visitors, search queries, or IPs where precision within a few percent is acceptable.

Use cases: daily active users (HyperLogLog), feature flags (Bitmap), user behaviour tracking (Bitmap).

-- ═══════════════════════════════
-- BITMAP: Track daily sign-ins
-- ═══════════════════════════════

-- User 42 signs in on day 0 of the year (Jan 1)
SETBIT signin:2026 42 1
-- (integer) 0  (was 0 before)

-- User 42 signs in again on day 100 (Apr 10)
SETBIT signin:2026 100 1

-- Has user 42 signed in at all?
GETBIT signin:2026 42
-- Returns: (integer) 1

-- How many users signed in on day 100?
BITCOUNT signin:2026 0 199

-- Users active on both day 100 and day 101? (intersection)
BITOP AND active_both signin:2026 day100 day101

-- ═══════════════════════════════
-- HYPERLOGLOG: Unique visitors
-- ═══════════════════════════════

-- Add visitor IPs to the hyperloglog key for today
PFADD visitors:2026-03-25 "192.168.1.1" "10.0.0.2" "172.16.0.3"
PFADD visitors:2026-03-25 "192.168.1.1"  -- duplicate, ignored

-- Approximate unique count
PFCOUNT visitors:2026-03-25
-- Returns: (integer) 3

-- Merge yesterday and today for weekly unique visitors
PFMERGE visitors:week12 visitors:2026-03-24 visitors:2026-03-25
PFCOUNT visitors:week12

Redis Streams — The Append-Only Log for Event Sourcing

Redis Streams (introduced in Redis 5.0) is an append-only log data structure. Each stream entry has a unique auto-generated ID (timestamp-sequence) and a set of field-value pairs — essentially a persistent, ordered, and replayable event log.

The key features are: non-destructive reads (consumers can read the same entry multiple times), consumer groups (competing consumers with acknowledgments), and blocking reads (like BRPOP but for streams). This makes Streams the natural choice for event sourcing, message queues with persistence, and audit trails.

Unlike Lists, entries in a stream are never removed by reading — they stay until explicitly trimmed (XTRIM) or evicted by maxlen. This allows replay and multiple consumer groups. Use XADD to append, XREAD to read in blocking mode, XREADGROUP for consumer groups, and XACK to acknowledge processed messages.

Streams also support range queries by ID, so you can replay historical events from a given point — invaluable for debugging or rebuilding state.

-- ═══════════════════════════════
-- STREAM: Order event log
-- ═══════════════════════════════

-- Add an event to the order stream (auto-generated ID using *)
XADD order:events * event_name "order_placed" user_id "42" amount "29.99"
-- Returns: "1700000000000-0" (timestamp-sequence)

XADD order:events * event_name "payment_received" user_id "42" amount "29.99"

XADD order:events * event_name "shipped" user_id "42" tracking "1Z999AA10123456784"

-- Read all events from the start (blocking, latest offset $)
-- Non-blocking: read from start to latest
XREAD COUNT 100 STREAMS order:events 0

-- Block until new events arrive (like BRPOP)
XREAD BLOCK 5000 STREAMS order:events $

-- Create a consumer group for competing consumers
XGROUP CREATE order:events order-processors $ MKSTREAM

-- Consumer 1: read and claim
XREADGROUP GROUP order-processors consumer-1 COUNT 10 BLOCK 2000 STREAMS order:events >

-- Acknowledge processing
XACK order:events order-processors 1700000000000-0

-- Trim the stream to keep only the last 1000 entries
XTRIM order:events MAXLEN ~ 1000
-- ~ means approximate trimming for efficiency