Why is Redis's INCR the correct way to implement a counter shared by many clients, and what happens if the key is missing, holds non-numeric text, or is incremented past the 64-bit range?

## The problem INCR solves Incrementing a shared number is the textbook lost-update scenario. If two clients each `GET counter` (both see 7), each adds one locally, and each `SET counter 8`, one increment vanished. No amount of client speed fixes it — the read and the write are separate operations with a gap in between. Redis's answer is to ship the operation, not the data: `INCR counter` tells the server to do the whole read-modify-write itself. Because Redis processes commands one at a time to completion, no other client's command can interleave inside it, so the increment is atomic with no locks, no retries and one round trip. ## Exact semantics **Missing key.** INCR on a key that does not exist treats the current value as 0, so it returns 1 and creates the key. This is why counters need no initialisation step — the first hit creates them. The same is true of INCRBY, DECR, DECRBY and INCRBYFLOAT. **Wrong content.** Redis strings are byte arrays; INCR parses the stored bytes as a base-10 signed integer each time. If the value is `"abc"`, has leading/trailing spaces, or is a float like `"1.5"`, the command fails with `ERR value is not an integer or out of range` and the stored value is left exactly as it was. It never silently resets to zero. If the key holds a different *type* (a list, a hash), you get `WRONGTYPE` instead. **Range and overflow.** The counter is a signed 64-bit integer: −9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Incrementing past the maximum returns the same "not an integer or out of range" error rather than wrapping around. If you need wrap-around or a narrower width, that is what BITFIELD's typed counters with OVERFLOW WRAP/SAT are for. **Floats.** `INCRBYFLOAT key 0.1` uses long-double arithmetic and reformats the stored value, stripping trailing zeros. It rejects `nan` and `inf` results with an error. There is deliberately no DECRBYFLOAT — you pass a negative increment. Be aware that the value is stored as text, so repeated float increments carry the usual binary-floating-point rounding; for money, count integer minor units with INCRBY instead. **TTL interaction.** This trips people up in rate limiters. A full `SET` clears the key's expiry; `INCR` does not. So the standard fixed-window limiter is: `INCR ratelimit:{user}:{minute}` and, only when the reply is exactly 1 (meaning you just created the window), `EXPIRE ratelimit:{user}:{minute} 60`. Every later increment inside the window leaves the countdown alone. Because those are two commands, a crash between them can leave a window key without expiry — embedding both in a small Lua script or using `SET ... NX EX` to seed the window removes that gap. ## Why the return value matters INCR replies with the value *after* the increment. That single fact makes it a general coordination primitive: - **Rate limiting** — act when the reply exceeds the quota. - **Sequence/ID generation** — the reply is your unique, monotonically increasing id (unique per key, and only as durable as your persistence settings, so do not treat it as a gapless database sequence). - **Idempotent fan-in** — increment a per-batch counter and let whoever receives the final expected number finish the job. - **Reference counting** — DECR and act when the reply hits 0. Because the whole decision is derived from an atomic reply, there is no window in which two clients both believe they were the winner. ## Common mistakes The first is reintroducing the race by reading afterwards: `INCR k` then `GET k` to "confirm" the value gives you someone else's number. Always use the reply. The second is thinking a MULTI/EXEC transaction around GET and SET fixes the lost update — queued commands cannot see each other's results, so you would need WATCH-based optimistic concurrency, which retries under contention; INCR simply avoids the problem. The third is assuming that because INCR is atomic, a *sequence* of INCRs across several keys is atomic — it is not; that requires a script. ## Durability caveat Atomic does not mean durable. An acknowledged INCR lives in memory and reaches disk only according to your persistence configuration, and replicas are updated asynchronously, so a counter can move backwards after an unclean failover. For billing-grade counting, treat Redis's counter as a fast aggregate and reconcile against a durable store.