auth
Web Sessions
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 preview 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.
Run an operation to see the raw engine response.
The in-browser engine is a preview build. Transactions, vector search, streams, tags and TTL are among the operations it doesn't implement yet.