Trace a role downgrade through this design. FastAPI writes the new permission set to Postgres. The edge still holds the old array under `session:<token>`, and the worker's check reads that array rather than the row [3][4]. Until an invalidation write lands, `data:write` is answered from a copy.
The post does name that step: logout or a permission change triggers invalidation from the origin [5]. The excerpt breaks off mid-route and never shows the endpoint [11], and the key shape is why that matters. Keys are per token [4], and the cached payload carries `user_id`, `tenant_id`, `permissions`, `email` and `expires_at` [6], with nothing mapping a user back to the token keys issued to them. Revoking one person with four live sessions is four deletes against keys the origin has to have remembered [5].
The cap does the safety work. `Math.min(ttl, 3600)` means an entry nobody manages to invalidate stops being servable within an hour of the write [4][1]. The worker also rejects any cached session whose `expires_at` has already passed, rather than trusting KV to have expired it [7]. That is careful work, and it narrows the exposure to one case: credentials still inside their validity window that should no longer carry the permissions attached to them.
Then the revalidation branch. When less than five minutes remain, the worker re-puts the object it already had, with `expirationTtl: cached.ttl` and an empty catch [8]. `SessionPayload` declares no `ttl`, so that argument is undefined [6][2]. More to the point, the branch never fetches the origin, so nothing on that path revalidates anything. The name describes an intention.
Now the number, which is a claim about the author's traffic in CitizenApp [10] rather than yours. Take the 60-80% at face value and back out the workload it implies. With one origin validation per token per hour as the ceiling [4], hit rate is roughly 1 - 1/N for N requests per token per hour, so 60% needs N of 2.5 and 80% needs N of 5 [3]. The same post describes session lookups running 200 or more times per second per user [2]. At that rate the hit rate rounds to 100 and the residual load is a rounding error, well under the 20-40% the quoted range leaves on Postgres [4]. Two hundred lookups per second per user is a figure I would want the trace for. The two numbers count different denominators, so neither one sizes your origin.
For the range to transfer you need repeat reads inside the TTL from the same token, sessions that outlive the TTL, and auth reads that dominate auth writes. Bursty logins from short-lived tokens give you the opposite: KV absorbs the tail, and the origin still eats the first read of every session, since misses fall through and write back [9].
In my context this ships, with the TTL set well below the 3600 ceiling and the deny path for write routes kept at the origin. What KV buys is a read cache at 200-plus locations for one line of binding config [9], and the operational relief the post claims against running Redis is real enough [1]. The price is that the TTL becomes a revocation SLA, and it should be picked by whoever owns offboarding rather than whoever owns p99.
