Per-user state on a shared tier uses an access-extended lifetime rather than a fixed one — what does that cost per request?
answer
- the deadline either moves or it does not
- moving a deadline is a write
- one write per authenticated request
- some stores can only rewrite the entry
basics
~20 sAn access-extended lifetime is pushed forward by each use, so every authenticated request must write to the tier as well as read from it. A read-mostly workload becomes roughly one write per request per active user.
solid answer
~50 sA fixed lifetime (counted from the write) leaves the entry alone while the user is active; an access-extended lifetime (pushed forward by each use) has to be moved on every request, and moving a deadline is a write. So the tier's write rate stops tracking sign-ins and starts tracking authenticated request volume. How big that write is depends on the store: some expose an operation that moves an existing entry's deadline without resending the value, some let the read itself carry the extension, and some offer no way to change a deadline at all — there the only route is writing the entry again, which on a store that keeps values as opaque bytes means shipping the whole state back each time. The usual mitigation is to extend lazily: only rewrite when the remaining lifetime has fallen below a chosen fraction of the full one.
go deeper
Know that a deadline on an entry is either counted once from the write or pushed forward by each use, and that only the first of those leaves the entry untouched while the user is active.
Explain that pushing a deadline forward is a write, count it per authenticated request rather than per sign-in, and say what the store must offer for that write to stay small.
Show the second-order effects — a write rate that tracks traffic, work reaching copies and disk, reads pinned to the node that takes writes — and the lazy-extension trick that removes most of them.
Decide whether the product's promise genuinely requires the deadline to move, and size the tier against peak authenticated request rate rather than against the number of signed-in users.
## Two ways to set a deadline on one entry An entry on a shared volatile tier can carry a deadline, and there are two ways to decide where that deadline sits. - A **fixed lifetime (counted from the write)** is set once, when the entry is written. Reading the entry does not move it. The entry disappears a known interval after it was stored, whatever the user did in between. - An **access-extended lifetime (pushed forward by each use)** is moved forward every time the entry is used, so an entry belonging to a busy user is continually pushed out of reach of its own deadline, and one belonging to an idle user drifts toward it. The behaviours the product wants are different, and so are the bills. This is the leaf where the second bill gets counted. ## Why extension is a write A deadline is not free-floating metadata that the tier maintains on the application's behalf. It is part of the entry's state on the server, and changing it means the server records a change. Whatever the shape of the call, the tier has to modify something it holds — and that is a write, with all of a write's consequences. | | Fixed lifetime | Access-extended lifetime | |---|---|---| | Writes while a user is active | one, at creation | roughly one per authenticated request | | What sets the write rate | sign-in rate | authenticated request rate | | An idle user's entry | goes at its deadline regardless | drifts toward its deadline | | Can a read be served away from the primary | on stores that allow replica reads, yes | no — an extension is a write | | What the tier must offer | a lifetime on write | some way to move an existing deadline, or a rewrite | ## How big the write is depends on the store This is where a claim that is true of the store you know best can be false of a real rival. Three genuinely different situations exist in this class: - **A deadline-only operation.** The store can move an existing entry's deadline without the value being resent. The write is tiny, but it is still an extra operation unless it can be bundled with the read. - **An extension carried by the read.** The store lets a read state a new deadline in the same operation, so the extension costs no extra round trip — only the write's downstream work. - **No way to change a deadline at all.** Extension then means writing the entry again, deadline and value together. On a store that keeps values as opaque bytes, the application must send the entire state back on every request, which makes an access-extended lifetime dramatically more expensive than it looks in a design document. Because of that spread, "we will expire it on inactivity" is not a decision you can cost without knowing what the tier in front of you offers. ## The bills that arrive later 1. **The write rate follows traffic.** Extension happens on the request path, so a traffic spike raises writes proportionally — at exactly the moment the tier is already at its busiest. 2. **Each write travels.** Writes are what copies of the tier receive and what anything the tier persists has to record. A read-only workload creates none of that; this one creates it per request. 3. **Reads can no longer go elsewhere.** On stores that let you read a copy, the read of this entry could be served there. The extension cannot, so these requests are pinned to the node that accepts writes for that key. 4. **Entry size stops being harmless.** Where extension means a full rewrite, a state entry that grew by one convenient field is now that much more traffic on every authenticated request. ## Paying less for the same behaviour 1. **Extend lazily.** Only push the deadline forward when the remaining lifetime has fallen below some fraction of the full one — a half, a quarter. Most requests then do no write at all, at the cost of a slightly generous inactivity boundary that is bounded by the fraction you picked. 2. **Keep one user's state under one key**, so an extension touches a single entry rather than several. 3. **Ask whether the deadline needs to move at all.** Where the product does not actually promise that activity keeps the state alive, a fixed lifetime removes the write from the request path entirely. ## What a strong answer sounds like It names the two lifetime shapes precisely, says out loud that extension is a write and not bookkeeping, converts that into a rate ("writes now equal authenticated requests, not sign-ins"), and then asks what the store actually gives it — because the difference between moving a deadline and rewriting an opaque value is the difference between a rounding error and the dominant cost on the path.
- How do you keep inactivity-based expiry without writing on every single request?Extend lazily. Read the entry's remaining lifetime and only push the deadline forward when it has fallen below a chosen fraction of the full one — a half or a quarter. Most requests then write nothing. The price is that the effective inactivity boundary becomes a little generous, by at most the fraction you chose, which is a number you can state rather than a surprise.
- Why can the extension not be served away from the node that takes writes?Because it is a write, and copies of a tier take writes from the primary rather than accepting their own. On stores that allow reading a copy, the read of this entry could go there, but the extension cannot — so an access-extended lifetime removes that option for this workload, and where the keyspace is split across nodes it also pins the request to the node holding that user's key.
saying these in an interview costs you the question
- Says extension is free because the request was already reading the entry
- Assumes every store can move a deadline without resending the value
- Calls the workload read-mostly after choosing extension on every access
- Claims the write rate is set by sign-ins rather than request volume
- Thinks a fixed lifetime is pushed forward simply by reading the entry