A new event is saved but visitors still see an old list. How do you reason about invalidation?

Say it in 30 seconds

Say it like this (20-30 seconds)

I trace every cache between the database and the screen. MiniTickets commits first, bumps a shared Redis generation, then requests invalidation of the web data cache. Old rebuilds can finish only into their old generation. Browser query state is another layer, and the web invalidation is asynchronous and can fail. So I would check which layer served the stale response rather than assume a successful database write made every visitor immediately fresh.

The deeper answer

Deleting one Redis key is not sufficient when a concurrent rebuild can write the old list back afterwards. A generation number changes the namespace for all filter keys. Readers capture it before reading data; a writer advances it only after the database commit. An old rebuild cannot populate the new namespace.

Invalidation proceeds from the data outward. Dropping the Next.js data cache before Redis is advanced could make it refill from the old Redis value. The web call is deliberately not awaited by the booking or event response, and failures are logged rather than turning a committed write into an apparent failure.

Generation invalidation trades simplicity for broad churn: every booking invalidates every filtered list. At high booking volume, that can erase much of the cache benefit. Options include accepting bounded stale seat counts for browsing or separating mutable availability from event metadata. Booking correctness still comes from the locked database transaction.

Counter-questions

Can stale-while-revalidate use an old generation?

The intended read path serves only the generation it captured. A reader already in flight can still return its earlier view; this is cache freshness management, not a linearizable read guarantee for the entire UI.

What if the web invalidation secret is wrong?

The hook rejects the request and the API logs a warning. The booking or event remains committed; web cache expiry and later refresh provide eventual recovery rather than rolling back that write.

Would you invalidate on every booking forever?

Only while the measured hit rate and database load justify it. Broad invalidation is easy to explain, but a busy sale may need separate metadata and availability caching.

Where in MiniTickets

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

apps/api/src/services/events.ts → invalidateEventLists

Work through the stale-cache case.