New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
Every single authenticated request runs a database query just to check who's making it.
What you'll have at the end
A session lookup served from Redis instead of a row read on every authenticated request, with the query count logged before and after
You need
A FastAPI dependency that runs on every authenticated route, looking up the caller's session by querying the sessions table in Postgres directly, and a Redis instance (or an equivalent key-value cache) the app can already reach.
Not covered
Rotating or invalidating every session a user holds at once, such as a forced logout-everywhere after a password change; that needs its own index of session ids per user and is a separate piece of work.
Leans on
Choose local caching or Redis
if you haven't already picked a cache for the app, that decision between an in-process cache and Redis is covered there first.
Namespace your cache keys so two different lookups never collide
if this session key's own namespace might collide with another lookup you're already caching, the pattern for keeping them apart is covered there.
Prove your cache is faster, never slower
to measure whether this actually cut request latency under your own real traffic, rather than just the query count this recipe checks, that's covered there.
Checked 19 Aug 2026
Part of the Backend Caching cookbook