Redis

Here is the sale from the top of the page, slowed down. Seat A12 has 1 ticket left. Server A reads "1". Server B reads "1". Both sell. Now two customers have the same seat.

The mistake is not Redis itself. The mistake is making the decision in the app: read, think, write across two network calls. Between those calls another server sneaks in, and neither server can tell that it happened.

The fix is to move the decision next to the data: tell Redis "if stock is still above 0, subtract 1 and tell me OK, else say sold out" in one step. The two diagrams below show the broken and the safe version side by side.

Before the clever commands, it helps to see the plain path most Redis traffic takes. Your app opens a connection to Redis and sends a short command like GET. Redis answers from memory. If the key is missing (a cache miss), the app loads the value from the database, then SETs it into Redis with a TTL (an expiry time) so stale copies clear themselves out later.

Redis handles one command at a time on its main loop (one at a time). That sounds limiting, but each command is tiny, so throughput is still huge for simple operations. It is also why the atomic commands later on this page are safe: nothing can interleave with a command that is already running.

This pattern pays off when many servers need the same hot data (sessions, popular profiles, feature flags), when you need a shared counter or limit such as "100 requests per minute per API key", or when you need a short lock or queue so only one worker processes a job right now.

The one condition is that the hot data fits in RAM. If the working set is huge and cold, keep Redis for the tip of the iceberg only; the Numbers to know section later on the page shows why memory is the budget you plan around.

When a single command cannot express the decision and MULTI/EXEC cannot branch, a Lua script fills the gap. It is a short program you send to Redis; Redis runs every line before helping the next client, which is how "check then change" with if/else logic stays safe.

KEYS = the Redis key names you will touch. ARGV = numbers and strings (limits, timestamps, tokens). Keep scripts short, and make no network calls from inside Lua. Prefer to pass "now" from the app as ARGV so replicas (copies of the data on other machines) replay the same decisions.

Day to day: load the script once, then call it with EVALSHA (run it by its fingerprint). If Redis restarts and returns NOSCRIPT, load again and retry.

-- Plain English:
-- 1) Drop requests older than the window
-- 2) If count is already at max, reject
-- 3) Otherwise record this request and allow
local key = KEYS[1]
local window = tonumber(ARGV[1])
local max = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local member = ARGV[4]
local min_score = now - window

redis.call('ZREMRANGEBYSCORE', key, 0, min_score)
local count = redis.call('ZCARD', key)
if count >= max then
  return {0, count}   -- {allowed?, current_count}
end
redis.call('ZADD', key, now, member)
redis.call('PEXPIRE', key, window)
return {1, count + 1}

-- Only delete the lock if I still own it
if redis.call('GET', KEYS[1]) == ARGV[1] then
  return redis.call('DEL', KEYS[1])
else
  return 0   -- someone else owns it now
end