Comparisons
Ten pairs that get conflated in real conversations. Neither column wins — what decides is the requirement. Each record leads with the confusion, because the confusion is the reason the record exists.
Authentication vs AuthorizationServer sessions vs TokensORM vs Raw SQLOptimistic vs Pessimistic concurrencySynchronous vs Asynchronous communicationOffset vs Cursor paginationLocal (in-process) vs Distributed cacheMonolith vs MicroservicesHorizontal vs Vertical scalingAt-least-once vs "Exactly-once"
Server sessions vs Tokens
What people get wrong about this pair
That a token is "stateless" is read as "no state anywhere". The state moved to the client, and with it the ability to revoke: a signed token stays valid until it expires, so real revocation means keeping a denylist — which is state again, just less obvious.
Server-side session
Use it when
First-party web apps where you want immediate revocation and are happy to look up state on each request.
Self-contained token (e.g. a signed JWT)
Use it when
Service-to-service calls and clients where a lookup per request is unwelcome, and where a short expiry is an acceptable revocation story.
| Dimension | Server-side session | Self-contained token (e.g. a signed JWT) |
|---|---|---|
| Where the truth lives | Server store keyed by session id | Inside the token, signed |
| Revocation | Delete the record; effective immediately | Not until expiry, unless you add a denylist |
| Per-request cost | A lookup in the session store | A signature verification |
| Scaling | Store must be shared across instances | No shared store needed for verification |
| Payload changes | Take effect on next request | Take effect only when a new token is issued |
| Leak impact | Session id useful until revoked | Token useful until it expires, everywhere it is accepted |