Your event cache expires and a hundred requests arrive together. What protects Postgres?

Say it in 30 seconds

Say it like this (20-30 seconds)

MiniTickets combines single-flight within each API process with a short Redis rebuild lock across processes. Requests for the same canonical filters and generation share work. Soft-expiry jitter spreads refreshes for different keys. These controls reduce duplicate database queries, but they are not a hard load cap: waiters eventually fall back to Postgres, and Redis errors remove cross-process coordination. I would measure misses and database saturation before assuming the cache guarantees protection.

The deeper answer

A single-flight map stores the running promise for one key and removes it on success or failure. Another process has its own map, so a Redis lock coordinates across tasks. The lock lasts five seconds and uses a random ownership token; its release script deletes it only if that token still matches.

A lock holder checks the cache again before rebuilding because another task may have filled it between the first read and lock acquisition. Non-holders wait fifty milliseconds before each of five fresh-value rechecks, then read Postgres themselves. That bounds added latency at the cost of allowing extra work under a slow rebuild.

The lock is suitable for rebuilding disposable cache data. It is unsuitable for the seat invariant: expiry or Redis failure can permit two holders. For production overload, combine cache coordination with admission control, bounded database work and alerts on the failure path.

Counter-questions

Does single-flight work when Redis is down?

It still shares matching reads inside one process. It cannot coordinate separate API tasks, and a request with a session cookie may fail its Redis session lookup before reaching this fallback.

Why compare the ownership token on release?

A slow holder can outlive its lease. Deleting unconditionally could remove a replacement holder’s lock; the atomic token comparison avoids that additional race.

Why allow waiters to query Postgres?

It avoids making a dead or slow cache holder block all readers. Under severe load that fallback can amplify pressure, so availability and database protection need an explicit balance.

Where in MiniTickets

Read Caching, then inspect the events-cache piece →.

apps/api/src/services/single-flight.ts → singleFlight