F-2 — Strings, Numbers, and Binary Safety

Useful for one-time tokens: generate a token, store it in Redis, consume it (get-and-delete) exactly once. No race condition between reading and deleting.

GETEX

# Get the value and set/modify its expiry atomically
GETEX session:user:1001 EX 3600      # reset TTL to 1 hour on access
GETEX session:user:1001 PERSIST      # remove TTL (make persistent)
GETEX session:user:1001 EXAT 1751299200  # set absolute expiry

GETEX is the correct way to implement sliding session expiry: every time the user makes a request, read their session and extend its TTL by another hour. Without GETEX, you would need a GET followed by an EXPIRE — two commands, two round-trips, and a race condition window.

GETSET (deprecated, use SET ... GET)

# Old pattern — still works, but SET ... GET is preferred
GETSET key newvalue

SETNX / SETEX (deprecated)

# Old: SETNX key value  →  New: SET key value NX
# Old: SETEX key seconds value  →  New: SET key value EX seconds

These still work but are considered legacy. Use the unified SET with options.

---

Batch Operations: MSET and MGET

Every Redis command requires a network round-trip. If you need to set or get 10 keys, 10 individual SET/GET calls means 10 round-trips. At 1ms per round-trip, that is 10ms of pure network latency.

MSET and MGET solve this:

# Set multiple keys in one command
MSET user:1001:name "Jatin" user:1001:email "jatin@example.com" user:1001:role "admin"
# OK
 
# Get multiple keys in one command
MGET user:1001:name user:1001:email user:1001:role
# 1) "Jatin"
# 2) "jatin@example.com"
# 3) "admin"

MSET is atomic in the sense that all keys are set together — no other command can see a partial write where some keys are set and others are not. However, it is not atomic in the transactional sense: if the server crashes mid-MSET, some keys may have been persisted and others not.

MGET returns values in the same order as the keys you requested. If a key does not exist, it returns nil for that position:

MGET user:1001:name user:9999:name
# 1) "Jatin"
# 2) (nil)

When to use MGET vs a Hash: If you are storing multiple fields for the same entity (user profile, product metadata), a Hash (HSET/HMGET) is usually better than multiple String keys. A Hash stores all fields under one key, keeping the entity together, supporting partial reads, and using more memory-efficient encoding for small field counts. The String multi-key pattern makes more sense when the fields are accessed independently rather than together.

MSETNX

# Set multiple keys only if NONE of them exist
MSETNX key1 val1 key2 val2 key3 val3
# Returns 1 if all keys were set, 0 if any key already existed (none are set)

MSETNX is all-or-nothing: either every key is set, or none are. Useful for initializing a group of related keys atomically.

---

Atomic Integer Operations

Redis's integer commands are one of its most useful features and most underused outside of simple counters.

INCR and DECR

SET page:views:homepage 0
 
INCR page:views:homepage   # → 1
INCR page:views:homepage   # → 2
INCR page:views:homepage   # → 3
 
DECR page:views:homepage   # → 2

INCR atomically increments the integer value by 1 and returns the new value. DECR decrements by 1. They fail with an error if the value is not an integer or exceeds the 64-bit signed long range.

The atomicity guarantee is important: if 1,000 concurrent clients all call INCR on the same key simultaneously, Redis processes each one serially (single-threaded). The final value will be exactly 1,000 — no lost updates, no race conditions, no need for locks. This is impossible to replicate safely with GET + application-side increment + SET.

# This is WRONG — race condition between GET and SET
val = redis.get('counter')
redis.set('counter', int(val) + 1)   # Two clients can both read 5, both write 6
 
# This is CORRECT — atomic
redis.incr('counter')

INCRBY and DECRBY

INCRBY page:views:homepage 10   # add 10
DECRBY stock:item:42 3          # subtract 3

INCRBYFLOAT

SET product:price:42 19.99
INCRBYFLOAT product:price:42 0.50   # → "20.49"
INCRBYFLOAT product:price:42 -2.00  # → "18.49"

INCRBYFLOAT works with floating-point values. It stores the result as a String (the encoding is always embstr or raw after a float operation, never int). The precision is limited to 17 significant digits. For financial data, use integers (store prices in cents) rather than floats.

The Counter Pattern in Production

Counters are the simplest Redis use case but appear everywhere:

# Rate limiting: how many API calls has this user made in this window?
INCR rate:api:user:1001:2025-05-29:14    # current hour bucket
EXPIRE rate:api:user:1001:2025-05-29:14 3600
 
# Page view tracking
INCR stats:page:homepage:views
 
# Inventory management
DECRBY stock:product:42 1
 
# Unique ID generation
INCR global:order:id   # always returns a unique, monotonically increasing ID

The ID generation pattern (INCR global:order:id) is worth highlighting: a single Redis INCR call gives you a unique, monotonically increasing integer ID without a database sequence or UUID generation. It is simple, fast, and works at high throughput — with the caveat that it is not durable without persistence configured.

---

APPEND: Building Strings Incrementally

SET log:session:1001 "2025-05-29T14:00:00 login"
APPEND log:session:1001 "\n2025-05-29T14:05:00 page_view"
APPEND log:session:1001 "\n2025-05-29T14:10:00 logout"
 
GET log:session:1001
# "2025-05-29T14:00:00 login\n2025-05-29T14:05:00 page_view\n2025-05-29T14:10:00 logout"

APPEND adds bytes to the end of an existing String value and returns the new length. If the key does not exist, it creates it first.

The use case is narrow: building up a string incrementally without reading it back each time. For log-like data at real scale, Redis Streams (F-7) are more appropriate because they support consumer groups and persistent delivery. But for simple, short-lived aggregations, APPEND works cleanly.

---

STRLEN: Getting the Length

SET name "Jatin Jain Saraf"
STRLEN name   # → 16

STRLEN returns the length of the string value in bytes, not in characters. For ASCII text this is the same. For multi-byte UTF-8 characters, a single character may be 2–4 bytes, so STRLEN can return a larger number than the character count.

---

SUBSTR and GETRANGE: Reading a Substring

SET greeting "Hello, Redis World"
GETRANGE greeting 0 4    # → "Hello"
GETRANGE greeting 7 11   # → "Redis"
GETRANGE greeting -5 -1  # → "World"  (negative index from end)

GETRANGE (historically also called SUBSTR) returns a substring without reading the entire value. Useful for reading a specific field from a fixed-format binary record stored as a Redis String, or for paging through large stored text.

---

The JSON Blob Anti-Pattern

Here is the pattern you will see in almost every Redis tutorial:

// "Cache" a user object
const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
await redis.set(`user:${userId}`, JSON.stringify(user), 'EX', 3600);
 
// Retrieve it
const cached = await redis.get(`user:${userId}`);
return JSON.parse(cached);

This works. It is also the source of several production problems that only appear at scale:

Problem 1: You cannot update a single field.

If the user changes their email, you must fetch the entire blob, deserialize it, update the field, re-serialize it, and write it back. Meanwhile another request might be doing the same thing. The update is not atomic — two concurrent updates can clobber each other.

Problem 2: You read the entire object even when you need one field.

If a middleware only needs user.role for authorization, you still deserialize a 2KB JSON blob to read a 10-byte string.

Problem 3: Serialization/deserialization CPU cost.

At 50,000 requests per second, deserializing 2KB JSON objects adds up. It is not Redis that is slow — it is your application spending CPU cycles on JSON parsing.

Problem 4: Large values block the event loop.

Redis's single-threaded architecture means reading or writing a very large String blocks all other commands. A 512KB JSON blob is a problem. A 50KB blob in a high-QPS system is worth thinking about.

The alternative: Use a Hash (HSET/HGET/HMGET) for structured objects. Redis Hashes store field-value pairs under a single key, support partial reads, and allow atomic field updates. Covered fully in F-3.

That said, JSON strings are not always wrong. They are appropriate when:

• The entire object is always read together
• The object is small (< 1–2 KB)
• You need to store arbitrary, dynamic structure that does not fit a fixed field schema
• You are using a language/library where Hash operations are awkward

The point is not to avoid JSON strings — it is to understand the trade-off and make the choice deliberately.

---

OBJECT ENCODING: Inspecting What Redis Actually Stores

As you work with Strings, use OBJECT ENCODING to verify what Redis is actually doing:

SET a 42
OBJECT ENCODING a           # "int"
 
SET b "short text"
OBJECT ENCODING b           # "embstr"
 
SET c "this string is longer than forty-four bytes total yes"
OBJECT ENCODING c           # "raw"
 
APPEND b " more text"       # modifying embstr converts it
OBJECT ENCODING b           # "raw"
 
SET d 3.14
OBJECT ENCODING d           # "embstr" (floats are stored as strings)

This matters when diagnosing memory usage. A key you expect to use int encoding but accidentally set as a float will use embstr instead, consuming more memory per key when you have millions of them.

---

Key Size Matters

Redis keys are themselves stored as Strings. Their size contributes to memory usage. Compare:

# 47 bytes of key name
SET user:profile:metadata:full:content:v2:1001 "value"
 
# 12 bytes of key name
SET u:p:1001 "value"

At 10 million keys, the difference between a 47-byte key and a 12-byte key is 350 MB of RAM — just for key names.

Guidelines:

• Keep keys under 20–30 bytes where possible
• Use the : separator convention but abbreviate entity names for high-volume keys
• For very high-volume keys (billions), consider numeric keys over string keys

The key name is not the place to be verbose. Your code comments are.

---

OBJECT FREQ and OBJECT IDLETIME

Two additional inspection commands round out what you can discover about a String key:

OBJECT IDLETIME mykey
# (integer) 42   — seconds since this key was last accessed
# Used by LRU eviction to decide which keys to evict
 
OBJECT FREQ mykey
# (integer) 5    — access frequency counter (only meaningful with LFU eviction policy)

These are diagnostic tools you will use when investigating which keys Redis is choosing to evict (covered in F-8).

---

Summary

• A Redis String is a binary-safe byte array, not a text string. It can hold arbitrary bytes up to 512 MB.
• Redis uses three internal encodings: int for integers (most efficient), embstr for short strings ≤ 44 bytes (cache-friendly), raw for longer strings.
• The full SET command supports expiry (EX, PX, EXAT, KEEPTTL), conditional writes (NX, XX), and atomic get-and-set (GET).
• GETDEL and GETEX provide atomic read-and-modify without a round-trip.
• MSET/MGET batch multiple operations into one round-trip — use them whenever you need multiple keys.
• INCR/INCRBY/INCRBYFLOAT are atomic counter operations with no race conditions.
• The JSON blob pattern works but has real costs at scale: no partial reads, no atomic field updates, serialization CPU, and event loop blocking for large values. Use Hashes for structured objects.
• OBJECT ENCODING tells you what Redis is actually storing — use it when diagnosing memory usage.

Next: F-3 — Lists, Hashes, Sets, and Sorted Sets — where we cover the data structures that make Redis genuinely different from every other cache, including the internal encoding switches that determine your memory footprint at scale.

---