Redis data structures and atomicity

The plate takes one lorry at a time: each load is weighed and booked in full before the next lorry drives on. The office keeps a tonnage tally, a card per farm, the lorry queue, the member register, a quality ranking board and a numbered log that inspectors initial.

At the weighbridge	In Redis
a lorry on the plate: 12 t booked to Farm 9's wheat line	HINCRBY, done in one step (step 3)
a farmer phones for the tally, adds 12 himself, phones back the total	GET, change, SET: other lorries are booked between the calls (step 4)
a convoy booked as one, with no lorry cutting in; a lorry that fails inspection is marked, the rest still booked	MULTI/EXEC (step 8)
a standing rule at the plate: "if the store has room, book the lorry; else turn it back"	a Lua script (step 9)
a "discard on 1 November" sticker on the whole card	a TTL on the key (step 6)
an uninitialled log entry, passed to another inspector	the pending list and XACK (step 10)

In real terms: Redis applies one command at a time, all of it; logic spanning several commands is atomic only inside MULTI/EXEC or a script.

Breaks down when: a weighmaster would notice a wrong total; Redis stores whatever SET sends. Wrong inference: "the server would notice a lost update." It cannot.

Contrasting case: a ledger on a table that anyone may rub out and rewrite: fine for one person, entries lost with three. That is a JSON string edited by clients.

4.1 ExamHall: the dashboard that counted one submission

EXH-704: after ECON-201 closed, the dashboard showed 1 submission, not 200. MR !1031 moved the counters from a JSON string to hash fields.

// before: two commands per submission
const s = JSON.parse(await r.get('exam:ECON-201:stats')); s.submitted += 1;
await r.set('exam:ECON-201:stats', JSON.stringify(s));
// after MR !1031: one command per submission
await r.hIncrBy('exam:ECON-201:stats', 'submitted', 1);

redis 7.4.9; 200 submissions at once on one connection
before  JSON string, GET + SET:  {"submitted":1,"flagged":3}
after   hash, HINCRBY:           submitted=200 flagged=3 · replies 1..200 each once: true
one field read: HGET submitted -> 200 · TYPE -> hash

All 200 GETs ran before the first SET, so every handler wrote 0 + 1 (step 4). Each HINCRBY replied a different count, 1 to 200 (steps 2–3).

4.2 ExamHall: the proctor flag queue

Flags are scored severity × 100000 − seconds into the exam: most severe first, then earliest. Two consoles claim with ZPOPMAX at once.

redis 7.4.9
ZRANGE 0 2 REV (top 3): f3 phone seen | f2 second face | f6 copy-paste
ZCARD 6 · rank of "f4 noise" from the top: 4
three rounds, both consoles at once: console A claimed 3, console B 3 · distinct flags 6 of 6 · left in queue 0

The server keeps the ranking (step 5); ZPOPMAX reads and removes in one command, so no flag is claimed twice (step 3). Which console wins varies, so only counts are shown.

4.3 Proof domain, ticketing: holds and TTLs

Times are offsets from a fixed virtual epoch T0; the last line uses real time.

redis 7.4.9; T0 = 4000000000 (virtual)
SET hold:e42:s12 fan7 NX EXAT T0+600 -> OK · same for fan9 -> null · holder fan7 · EXPIRETIME T0+600
plain SET over it -> EXPIRETIME -1 (-1 = no TTL: SET replaced the value and its TTL)
SET ... KEEPTTL -> value fan8 · EXPIRETIME T0+600
HSET on a hash with a TTL -> EXPIRETIME T0+900 · INCR on a counter with a TTL -> EXPIRETIME T0+900
HEXPIREAT cart:fan7 T0+600 FIELDS 1 s12 -> [1] · HEXPIRETIME s12 T0+600, s13 -1 · key EXPIRETIME -1
a TTL on one set member: SEXPIRE -> ERR unknown command 'SEXPIRE'
after 400 ms: hold:e42:s14 (PX 50) -> null · cart:fan3 (s14 HPEXPIRE 50) -> {"s15":"hold"}

SET … NX takes a seat and its TTL in one command. A plain SET drops the TTL; KEEPTTL, HSET and INCR keep it (step 7). One hash field can expire alone; a set member cannot (step 6).

4.4 Proof domain, ticketing: a promo code in MULTI and in Lua

Code SPRING allows 3 redemptions, one per fan; 12 fans try at once on 4 connections.

if redis.call('SISMEMBER', KEYS[2], ARGV[1]) == 1 then return 'already' end
if redis.call('SCARD', KEYS[2]) >= tonumber(ARGV[2]) then return 'sold out' end
redis.call('SADD', KEYS[2], ARGV[1]); return 'redeemed'

redis 7.4.9
raw MULTI session: MULTI -> OK · SCARD -> QUEUED · SADD -> QUEUED · EXEC -> [0,1]
Lua, 12 fans at once on 4 connections: redeemed 3 · sold out 9 · SCARD 3 · a winner trying again -> already

Inside MULTI, SCARD answers QUEUED; its count arrives with EXEC, after the SADD ran, so code cannot branch on it (step 8). The script reads, checks and writes as one command (step 9).