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

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)

SETNX / SETEX (deprecated)

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:

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:

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

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

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.

INCRBY and DECRBY

INCRBYFLOAT

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:

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

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

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

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:

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:

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:

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:

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.

---