SET with expiry (EX, PX) in Redis - Deep Dive

Overview - SET with expiry (EX, PX)

What is it?

In Redis, the SET command stores a value under a key. The EX and PX options let you set an expiration time for that key, so it automatically disappears after a certain period. EX sets the expiry in seconds, while PX sets it in milliseconds. This helps manage temporary data easily.

Why it matters

Without expiry, data in Redis would stay forever unless manually deleted, which can cause memory overload and stale information. Expiry lets Redis automatically clean up old data, saving memory and keeping data fresh. This is crucial for caching, sessions, and temporary tokens.

Where it fits

Before learning SET with expiry, you should understand basic Redis commands like SET and GET. After this, you can learn about other expiration commands like EXPIRE and TTL, and how Redis handles key eviction and persistence.

Mental Model

Core Idea

Setting a key with expiry in Redis means the key lives only for a set time, then vanishes automatically.

Think of it like...

It's like putting a note on your fridge that self-destructs after a set time, so you don't have to remember to throw it away.

┌───────────────┐
│ SET key value │
└──────┬────────┘
       │
       ▼
┌─────────────────────────────┐
│ SET key value EX 10 (seconds)│
│ or SET key value PX 5000 (ms)│
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Key stored with expiry timer │
│ Key auto-deletes after time  │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Basic SET command in Redis

Concept: Learn how to store a value under a key using SET.

The SET command stores a string value under a key. Example: SET mykey "hello" This saves the value "hello" under the key "mykey".

Result

OK The key "mykey" now holds the value "hello".

Understanding how to store data is the first step before adding expiry controls.

2

Foundation

Why expiry matters in Redis

Concept: Understand the need for automatic data removal to save memory and keep data fresh.

Without expiry, keys stay forever unless deleted manually. This can fill up memory and cause outdated data. Expiry lets Redis remove keys automatically after a set time.

Result

Keys with expiry free memory automatically and keep data relevant.

Knowing why expiry exists helps you appreciate its role in managing Redis memory and data lifecycle.

3

Intermediate

Using EX option for expiry in seconds

🤔Before reading on: do you think EX sets expiry in milliseconds or seconds? Commit to your answer.

Concept: EX sets the expiry time in seconds when using SET.

Example: SET session_token "abc123" EX 60 This stores the key "session_token" with value "abc123" and expires it after 60 seconds.

Result

OK The key will be deleted automatically after 60 seconds.

Understanding EX lets you control key lifetime in whole seconds, useful for many time-based scenarios.

4

Intermediate

Using PX option for expiry in milliseconds

🤔Before reading on: do you think PX expiry is more precise or less precise than EX? Commit to your answer.

Concept: PX sets the expiry time in milliseconds, allowing finer control.

Example: SET temp_data "value" PX 1500 This stores "temp_data" with value "value" and expires it after 1.5 seconds (1500 ms).

Result

OK The key expires after 1500 milliseconds.

Knowing PX allows you to set very short-lived keys, useful for precise timing needs.

5

Intermediate

Combining SET with expiry and NX/XX options

🤔Before reading on: do you think expiry works with conditional SET options like NX or XX? Commit to your answer.

Concept: You can combine expiry with conditions to set keys only if they exist or don't exist.

Example: SET mykey "newvalue" EX 30 NX This sets "mykey" only if it does not exist, with 30 seconds expiry. Similarly, XX sets only if key exists.

Result

OK if condition met, else null reply. Expiry applies only if key is set.

Combining expiry with conditions lets you safely update keys with controlled lifetime.

6

Advanced

Expiry precision and Redis internal timers

🤔Before reading on: do you think Redis deletes expired keys exactly at expiry time or with some delay? Commit to your answer.

Concept: Redis uses internal timers and lazy deletion, so expiry is approximate, not exact.

Redis checks for expired keys in two ways: - Passive: when a key is accessed, it checks expiry and deletes if expired. - Active: Redis randomly samples keys with expiry and deletes expired ones. This means keys may live slightly longer than expiry time.

Result

Keys expire close to set time but not always instantly.

Knowing expiry is approximate helps design systems tolerant to small timing variations.

7

Expert

Expiry behavior with persistence and replication

🤔Before reading on: do you think expiry times are preserved exactly after Redis restarts or replication? Commit to your answer.

Concept: Expiry times are saved in persistence and replicated, but exact timing can vary after restart or failover.

Redis saves expiry timestamps in RDB and AOF files. After restart, keys expire based on saved timestamps. In replication, expiry is propagated but network delays can cause slight differences. Also, expired keys might persist briefly after failover.

Result

Expiry is preserved but timing precision can vary in distributed setups.

Understanding expiry in persistence and replication helps build reliable distributed Redis applications.

Under the Hood

When you use SET with EX or PX, Redis stores the key's value along with an expiry timestamp internally. Redis maintains a data structure to track keys with expiry. It uses two methods to remove expired keys: lazy deletion (checking expiry when keys are accessed) and active expiration (periodically scanning keys with expiry). This design balances performance and memory usage.

Why designed this way?

Redis was designed for speed and low latency. Immediate deletion of expired keys would slow down operations. Lazy and active expiration allow Redis to efficiently manage memory without blocking commands. Storing expiry timestamps with keys ensures expiry survives restarts and replication.

┌───────────────┐
│ SET key value │
└──────┬────────┘
       │
       ▼
┌─────────────────────────────┐
│ Store value + expiry time    │
│ (timestamp = now + EX/PX)   │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Expiry tracking structure    │
│ (keys with expiry timestamps)│
└─────────────┬───────────────┘
              │
  ┌───────────┴───────────┐
  │                       │
  ▼                       ▼
Lazy deletion          Active expiration
(check on access)     (periodic scanning)
  │                       │
  ▼                       ▼
Delete if expired    Delete expired keys

Myth Busters - 4 Common Misconceptions

Quick: Does SET with EX guarantee the key is deleted exactly at expiry time? Commit yes or no.

Common Belief: SET with EX deletes the key exactly when the expiry time is reached.

Reality: Redis deletes expired keys approximately, not exactly at expiry time, due to lazy and active expiration methods.

Why it matters: Assuming exact expiry can cause bugs if your application relies on precise timing for key removal.

Quick: If you SET a key with expiry, does updating the key without expiry remove the expiry? Commit yes or no.

Common Belief: Setting a key again without expiry removes any previous expiry.

Reality: Yes, setting a key without expiry overwrites the old expiry, making the key persistent unless expiry is set again.

Why it matters: Not knowing this can cause keys to live longer than intended, leading to stale data.

Quick: Does PX accept fractional milliseconds like 1.5 ms? Commit yes or no.

Common Belief: PX can accept fractional milliseconds for expiry precision.

Reality: PX only accepts integer milliseconds; fractional values are not supported.

Why it matters: Trying to use fractional milliseconds will cause errors or unexpected behavior.

Quick: Does expiry time reset if you read a key with expiry? Commit yes or no.

Common Belief: Reading a key with expiry resets its expiry timer.

Reality: No, reading a key does not affect its expiry time; expiry counts down independently.

Why it matters: Misunderstanding this can cause confusion about why keys expire despite frequent reads.

Expert Zone

1

Expiry times are stored as absolute timestamps internally, not relative durations, which affects how expiry behaves after server restarts.

2

Combining SET with expiry and conditional flags (NX/XX) can be used to implement atomic locks with automatic expiration.

3

Redis does not guarantee immediate deletion of expired keys, so applications should handle possible stale reads gracefully.

When NOT to use

Do not use SET with expiry for data that must never be lost or for critical data requiring guaranteed persistence. Instead, use persistent storage or databases with transactional guarantees. For very precise timing, consider external schedulers or TTL management outside Redis.

Production Patterns

In production, SET with expiry is widely used for session management, caching with automatic invalidation, distributed locks with NX and expiry, and rate limiting by setting keys with short expiries. Combining expiry with Lua scripts ensures atomic operations.

Connections

Cache Invalidation

SET with expiry is a core technique to implement cache invalidation by automatically removing stale cache entries.

Understanding expiry in Redis helps grasp how caches stay fresh without manual cleanup.

Distributed Locking

Using SET with NX and expiry implements distributed locks that auto-release after timeout.

Knowing expiry behavior is critical to avoid deadlocks or stale locks in distributed systems.

Biological Cell Lifespan

Expiry in Redis is like programmed cell death where cells live for a set time then die to keep the organism healthy.

This cross-domain view shows how automatic expiry maintains system health by removing old data.

Common Pitfalls

#1 Setting a key with expiry but then overwriting it without expiry unintentionally.

Wrong approach:

SET mykey "value1" EX 60
SET mykey "value2"

Correct approach:

SET mykey "value1" EX 60
SET mykey "value2" EX 60

Root cause:

Not realizing that the second SET without expiry removes the expiry timer.

#2 Using EX and PX together in one SET command.

Wrong approach:

SET mykey "value" EX 10 PX 5000

Correct approach:

SET mykey "value" EX 10
-- or --
SET mykey "value" PX 5000

Root cause:

Redis does not allow both EX and PX in the same SET command; only one expiry option is valid.

#3 Expecting keys to expire exactly on time without delay.

Wrong approach:

Assuming key is deleted immediately at expiry and writing code that fails if key still exists a moment later.

Correct approach:

Design code to tolerate slight delays in key expiry due to Redis's lazy and active expiration.

Root cause:

Misunderstanding Redis's expiry mechanism and timing precision.

Key Takeaways

SET with EX or PX in Redis stores a key with an automatic expiry time in seconds or milliseconds.

Expiry helps manage memory and data freshness by automatically deleting keys after a set time.

Redis expiry is approximate, using lazy and active deletion methods, so keys may live slightly longer than set time.

Setting a key without expiry overwrites and removes any previous expiry timer.

Combining expiry with conditional SET options enables powerful patterns like distributed locks and safe cache updates.