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.

Practice

1. What does the EX option do when used with the Redis SET command?

easy

A. Sets the key to expire after a specified number of seconds

B. Sets the key to expire after a specified number of milliseconds

C. Sets the key without any expiration

D. Deletes the key immediately after setting it

Solution

1. Step 1: Understand the EX option in Redis SET

   The EX option sets the expiration time in seconds for the key.

2. Step 2: Compare EX with other expiry options

   PX sets expiry in milliseconds, so EX is specifically for seconds.

3. Final Answer:

   Sets the key to expire after a specified number of seconds -> Option A

4. Quick Check:

   EX = seconds expiry [OK]

Hint: EX means seconds expiry, PX means milliseconds expiry [OK]

Common Mistakes:

• Confusing EX with PX and thinking EX is milliseconds
• Assuming EX sets no expiry
• Thinking EX deletes the key immediately

2. Which of the following is the correct syntax to set a key session with value abc123 that expires in 10 seconds using Redis?

easy

A. SET session abc123 EXPIRE 10

B. SET session EX 10 abc123

C. SET session abc123 PX 10

D. SET session abc123 EX 10

Solution

1. Step 1: Recall Redis SET command syntax with expiry

   The correct syntax is: SET key value EX seconds.

2. Step 2: Check each option for correct order and keyword

   SET session abc123 EX 10 matches the correct order and uses EX for seconds expiry.

3. Final Answer:

   SET session abc123 EX 10 -> Option D

4. Quick Check:

   SET key value EX seconds = correct syntax [OK]

Hint: Remember: SET key value EX seconds [OK]

Common Mistakes:

• Placing EX before the value
• Using PX instead of EX for seconds
• Using EXPIRE keyword inside SET command

3. What will be the output of the following Redis commands executed in order?

SET temp 100 PX 5000
TTL temp

medium

A. An integer close to 5

B. 5

C. 0

D. -1

Solution

1. Step 1: Understand PX expiry in SET command

   PX 5000 sets the key to expire in 5000 milliseconds (5 seconds).

2. Step 2: Interpret TTL command output

   TTL returns time to live in seconds. Since expiry was set in milliseconds, TTL rounds to nearest second.

3. Step 3: Predict TTL value

   TTL will return an integer close to 5 seconds, depending on execution time.

4. Final Answer:

   An integer close to 5 -> Option A

5. Quick Check:

   PX 5000 ms = ~5 seconds TTL [OK]

Hint: TTL returns seconds even if PX used for expiry [OK]

Common Mistakes:

• Expecting TTL to return milliseconds
• Thinking TTL returns 0 immediately
• Assuming TTL returns -1 for keys with expiry

4. Identify the error in this Redis command:

SET user123 "John" EXPIRE 20

medium

A. Value should not be in quotes

B. EXPIRE is not valid inside SET command

C. Missing quotes around key

D. EXPIRE should be PX for milliseconds

Solution

1. Step 1: Check Redis SET command syntax

   SET command uses EX or PX for expiry, not EXPIRE keyword.

2. Step 2: Identify misuse of EXPIRE keyword

   EXPIRE is a separate command, not an option inside SET.

3. Final Answer:

   EXPIRE is not valid inside SET command -> Option B

4. Quick Check:

   Use EX or PX inside SET, not EXPIRE [OK]

Hint: Use EX or PX with SET, EXPIRE is separate command [OK]

Common Mistakes:

• Using EXPIRE inside SET command
• Confusing EXPIRE command with expiry option
• Misplacing quotes around key or value

5. You want to store a temporary API token in Redis that expires exactly after 1500 milliseconds. Which command correctly sets the key api_token with value xyz789 and the required expiry?

hard

A. SET api_token xyz789 EX 1.5

B. SET api_token xyz789 EX 1500

C. SET api_token xyz789 PX 1500

D. SET api_token xyz789 PX 1.5

Solution

1. Step 1: Determine correct expiry option for milliseconds

   PX sets expiry in milliseconds, EX uses seconds only.

2. Step 2: Check value format for PX

   PX requires integer milliseconds, so 1500 is valid, decimals like 1.5 are invalid.

3. Step 3: Validate each option

   SET api_token xyz789 PX 1500 uses PX 1500 correctly; others use wrong units or decimals.

4. Final Answer:

   SET api_token xyz789 PX 1500 -> Option C

5. Quick Check:

   Milliseconds expiry = PX integer value [OK]

Hint: Use PX with integer milliseconds for precise expiry [OK]

Common Mistakes:

• Using EX with decimal seconds
• Using PX with decimal instead of integer
• Confusing EX and PX units