Should the events page serve old data when Postgres is down?

Say it in 30 seconds

Say it like this (20-30 seconds)

For browsing, bounded stale data can be better than an error. MiniTickets serves the current cached generation while it refreshes in the background, with a five-minute hard age limit. A failed refresh preserves that copy; a miss cannot invent one, and booking still requires Postgres. This trades freshness for availability only on this read path. It does not make the whole application independent of Redis, authentication or the database.

The deeper answer

Freshness has two thresholds. The default soft TTL is thirty seconds with up to ten percent jitter. After that, readers receive the stale list while refresh work runs. The hard TTL is five minutes, and the code checks age as well as relying on Redis expiry. After that boundary, the old copy must not be served.

The stale-if-error label reflects a failed background refresh in that API process. It is diagnostic state, not a guarantee that every task has observed the same failure. A newly invalidated generation is empty, so the service must not resurrect a previous generation merely because Postgres is unavailable.

This is appropriate for approximate browsing information. It would be unsafe as the authority for selling a seat. Also, Redis lookup for a supplied session cookie happens before the events service: an outage there can fail the request before any cache fallback. Production error budgets should separate anonymous browsing, authenticated browsing and booking.

Counter-questions

What happens on the first request after hard expiry?

It is a cache miss. If Postgres is still unavailable, the request fails because there is no usable copy within the allowed age.

Can a lost background refresh lose a confirmation?

No confirmation should use this pattern. A process can exit before a cache refresh finishes; required work belongs in the durable outbox and queue path.

Why not serve stale data indefinitely?

It hides prolonged failure and can mislead users about event existence or availability. A hard age bound makes the freshness promise explicit, even though it eventually reduces availability.

Where in MiniTickets

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

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