auth
Web Sessions
Who owns this session?
Server-side sessions keyed by token, expired by the database.
A hash-only table where every read is a token lookup. The interesting part is not the read, it is the deletion: a numeric expiresAt attribute hands cleanup to DynamoDB's TTL instead of a sweep job, so the table stays bounded without anyone writing a cron.
The model
Session
A signed-in session, valid until its expiry.
- pk
- SESSION#<token>
Attributes: userId (S), expiresAt (N), createdAt (N), userAgent (S)
Access patterns
- GetItemResolve a session token
Fetch the session behind a token, if it has not expired.
Design notes
TTL is a design here, not a live demonstrationtrade-off
The in-browser engine runs no background expiry, so every seeded session stays in the table and you can read the expired ones. Real DynamoDB deletes them too, but on its own schedule: AWS documents typically within a few days of expiresAt passing, with no guarantee attached. It is background work, not a trigger.
Presence is not validitywhy
Two of the five seeded sessions have passed their expiresAt and are still sitting in the table, because TTL deletion lags. So an application compares expiresAt to the clock rather than treating a row's existence as proof it is still good - a signed-out-by-expiry user whose row has not been swept yet must not be let back in.
Why not delete on sign-outtrade-off
Explicit deletion still makes sense for sign-out, since that is a deliberate act. TTL covers the far commoner case of a session nobody ever closes, which is otherwise a growing table and a write-heavy sweep to keep it in check.
Taught in the course
- The key is the address - GetItem needs the whole primary key: partition and sort.
Fetch the session behind a token, if it has not expired.
Choose an access pattern above, or build your own request. See what comes back and what it costs.
Write transactions, streams, tags and TTL are among the operations this browser build leaves out. dynoxide's native build has them.