Our per-tenant limit was 100 requests per second, yet one tenant pushed 310 through to a partner API that then blocked us. The Redis limiter read the counter, decided in Node, then wrote back. Moving the whole token bucket into one Lua script fixed it.
We took a Laravel API from 300 to 4,000 requests per second without rewriting it. The wins came from four layers: Octane workers, a layered cache, Horizon queues with separate supervisors, and read replicas with sticky writes. Here is the setup and the traps.
We removed Redis from a mid-sized SaaS stack and moved its cache, job queue and pub/sub into Postgres. Here is the schema we used, the limits we measured, the traps we hit, and the signals that tell you to bring Redis back.
Our game released 100 limited items at 20:00, and about 20,000 players tapped claim within seconds. 140 players received one. The endpoint checked remaining stock, then decremented it separately. How we proved the race and fixed it with an atomic conditional update, a constraint and a Redis gate.
Our support chat showed messages out of order, double ticks that never turned blue, and duplicates after reconnects. We rebuilt delivery around per-conversation sequence numbers, client message ids, device cursors and read watermarks. This is the protocol, schema and code.
We added a semantic cache to our help assistant to cut LLM cost. Within days a user asking how to cancel a subscription got instructions for cancelling an order. The two questions were 0.92 similar. We added exact-match first, scoped keys, intent gating and a measured threshold.
Our monthly statement job used a Redis SET NX lock with a 30 second TTL. One slow run outlived the TTL, a second worker took the lock, and 214 customers got duplicated statement lines. Here is why a TTL lock alone cannot be safe and how fencing tokens closed the gap.
Users were logged out at random, mostly in the afternoon. Sessions and a fast-growing cache shared one Redis with allkeys-lru, so every hourly cache warm-up evicted idle sessions. Separate DB numbers would not have helped; separate instances did.
Every ten minutes our catalog API spiked to 4-second responses and the database hit 100% CPU. A hot Redis key expired and 600 requests rebuilt it at once. Single-flight, a short Redis lock, stale-while-revalidate and TTL jitter fixed it.