Invalidation, the hard part

A TTL is a floor, not a correctness guarantee

A 60-second TTL means "this can be at most 60 seconds stale" — it does NOT mean "this will always be fresh within 60 seconds." If a walker edits their price the instant after you cache the list, every reader sees the old price for up to 60 more seconds. For a directory listing that's a shrug. For anything that must reflect a write immediately, TTL alone isn't enough — you need explicit invalidation: delete the cache key the moment the underlying data changes, so the next read is forced to miss and re-fetch fresh.

The pattern is simple: any endpoint that writes to the walkers table also deletes walkers:list in the same request, right after the write commits. The next GET /walkers finds nothing cached, falls through to Postgres, and re-populates the key with the new data.