Session store placement
A session design must say where the state lives and how a revoke reaches every reader. 5 million sessions of 1 KB need about 5 GB. A shared store rejects a revoked session within 1 s, and a local copy in each server cannot.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | Local cache of 60 s in each server | Shared session store |
|---|---|---|---|
| p99 latency | under 150 ms | 70 ms Pass | 70 ms Pass |
| Data age | under 1 s | 29.9 s Fail | 0 ms Pass |
| Monthly cost | 88 USD/mo | 80 USD/mo | |
| Error rate | 0% | 0% |
Key numbers
| Number | Value |
|---|---|
| Cache read, median | 0.1 ms |
| Reads per second, one cache | 100,000 ops/s |
| Cache memory price | 5 USD/GB-mo |
Lasers in orbit, New York to London · 7,151 km · 24 ms one way
How it works
Session state can live in three places. It can sit in the token that the client carries, in the memory of each server, or in a shared store. Each place has a different answer to one question: how fast does a revoke reach every server?
A signed token holds its own state. Servers need no store, so reads are fast and cheap. But a server cannot undo a token that it has signed, except by waiting for it to expire or by checking a list.
A copy of the session in each server has the same problem. In the mini board operators revoke about 5 sessions/s, and every server must reject a revoked session within 1 s. A local cache with a 60 s life serves session data that is up to 29.9 s old, so it misses that limit.
A shared store keeps one copy of each session. A revoke changes that copy, and the next read on any server sees it. Five million sessions of about 1 KB need about 5 GB of memory before overhead. At 5 USD per GB-month the memory costs about 26 USD/mo. A read takes about 0.1 ms.
In the levels you decide where state lives and measure how old a read can be.