Learning Redis - Strings, Numbers & Key Management

#Introduction

After understanding the architecture in episode 2, it's time to explore data structures. Episode 3 opens with Strings — the most fundamental and most widely used data type in Redis — plus two important skills: atomic numeric operations and proper key management.

Strings may look simple, but this is where the foundation for caching, sessions, counters, and rate limiting is built. You'll also learn the critical habits that separate beginners from professionals: why KEYS is dangerous, how SCAN is the answer, and how TTL prevents memory leaks. Let's begin.

#Strings: SET and GET

#Writing and Reading

Strings can hold text, numbers, or even binary data up to 512MB. The most basic operations:

redis-cli SET user:1 name "Arman"
redis-cli GET user:1

SET user:1 name "Arman" stores a value, and GET user:1 reads it back. Note the naming user:1 — Redis has no built-in namespace, so a key naming convention like entity:id:field becomes your responsibility (we cover this in episode 16).

#MSET and MGET

To write and read many keys at once, use the multi versions:

redis-cli MSET user:1:name "Arman" user:1:email "arman@example.com"
redis-cli MGET user:1:name user:1:email

MSET and MGET save network round-trips — one command instead of many. This is the simplest form of batching, and in episode 9 you'll see more powerful techniques.

#SET Options: EX, NX, XX

SET is far richer than just writing a value. The EX option gives an expiry in seconds, NX writes only if the key doesn't exist, and XX writes only if the key already exists:

redis-cli SET session:abc123 "active" EX 3600
redis-cli SET lock:deploy "owner-1" NX
redis-cli SET lock:deploy "owner-2" NX

The first line creates a key valid for one hour. The second line succeeds because the key doesn't exist yet. The third line returns nil — NX rejects it because the key already exists. The SET key value NX PX milliseconds pattern is what forms the basis of distributed locks (episode 11).

#Numeric Operations on Strings

#Atomic Counters

Numbers are stored as strings, but Redis provides arithmetic operations that run atomically on the server — safe under concurrency with no race conditions:

redis-cli INCR page:views
redis-cli INCRBY page:views 10
redis-cli DECR cart:items
redis-cli INCRBYFLOAT balance:1 0.50

INCR adds one, INCRBY adds a given value, DECR subtracts, and INCRBYFLOAT handles decimal numbers. Because Redis execution is single-threaded, two requests calling INCR at the same time will never pass a single increment — the result is always correct. This is the foundation for view, vote, and stock counters.

#Why Atomic Counters Matter

Without atomicity, two requests that read 5 and then write 6 simultaneously could both produce 6 and lose one increment — this is the classic race condition. With INCR, Redis guarantees each increment is applied exactly once, no matter the concurrency level.

#Key Management

#KEYS vs SCAN

KEYS * is easy, but dangerous: it scans the entire keyspace at once and blocks the server during execution — violating the single-threaded principle we discussed in episode 2. Never use it in production.

redis-cli SCAN 0 MATCH user:* COUNT 100

SCAN 0 MATCH user:* COUNT 100 iterates in incremental steps using a cursor. The server returns a new cursor; you keep passing that cursor until the reply is 0 (done). SCAN provides a guarantee that each element will be seen at least once, without blocking the server. Keep this whole batching pattern in mind.

#EXISTS, DEL, UNLINK, TYPE, RENAME

Manage the lifecycle of keys with these commands:

redis-cli EXISTS user:1
redis-cli TYPE user:1
redis-cli RENAME user:1 user:1:renamed
redis-cli DEL user:1:renamed

EXISTS returns 1 if it exists, TYPE shows the data type, RENAME renames the key. Note the difference between DEL and UNLINK: DEL deletes synchronously (blocking if the key is large), while UNLINK deletes asynchronously in the background — the right choice for large keys.

#Key Expiration (TTL)

#Setting and Reading a Key's Lifetime

TTL is the defining feature of Redis as a cache. A key with a TTL is automatically deleted by the server after it expires — no manual cleanup code needed:

redis-cli SET temp "data" EX 120
redis-cli TTL temp
redis-cli PEXPIRE temp 60000

SET temp "data" EX 120 gives a lifetime of 120 seconds. TTL temp shows the remaining seconds (-1 means no TTL, -2 means the key doesn't exist). PEXPIRE works in milliseconds for finer control. PERSIST removes the TTL so the key lives forever.

#How Expiry Works in Redis

Redis removes expired keys in two ways: lazy (deleted when accessed) and active (periodic background sampling). That's why TTL is a cheap operation — there is no per-key scheduler, but an efficient sampling mechanism.

#Summary

Episode 3 equipped you with the Strings data type complete with atomic numeric operations and key management: SET/GET/MSET/MGET, the EX/NX/XX options, the INCR counter family, SCAN as the safe replacement for KEYS, and TTL management.

Key takeaways:

• Strings hold text, numbers, up to 512MB; MSET/MGET save round-trips.
• SET key value EX 3600 adds an expiry; NX/XX provide conditional semantics.
• INCR and its counter family run atomically — safe under concurrency.
• KEYS * blocks the server; use SCAN with a cursor in production.
• UNLINK deletes asynchronously for large keys; DEL is synchronous.
• EXPIRE, TTL, and PERSIST manage the key lifecycle.

In the next episode, episode 4, we cover Lists & Hashes — structures for queues and objects. Lists for queues with the blocking operations BLPOP/BRPOP, and Hashes for storing objects like user profiles and session data. Get your redis-cli ready!