Sign-out deletes a user's state entry from the shared tier — which copies of that state does the deletion fail to reach?
answer
- one delete, several holders
- the tier keeps copies of its own
- an instance may still hold it
- you cannot delete a device's copy
- assert revoked rather than rely on absence
basics
~20 sDeleting the entry ends the copy on the node that took it. A copy inside the tier that has not received it yet, one an application instance still holds in memory, and the client's own copy all survive.
solid answer
~50 sA delete is an ordinary write and reaches what an ordinary write reaches. Inside the tier, on stores that acknowledge before any copy holds the write, a failover in that gap can promote a copy that still has the entry — others in this class acknowledge only once a copy has it, and some let you ask for that per call, so check rather than assume. Inside the application, an instance holding the state for the current request, or keeping a short local copy to skip the round trip, is told nothing. And the client holds a copy the server cannot reach at all. So sign-out is only as complete as the paths that consult the tier: where a request can be authorised without reading that entry, its absence is a verdict nobody asks for, and revocation has to be something each request checks.
go deeper
Know that signing out must get rid of the user's state, and that the same state may exist in more than one place at the moment you remove it.
Name the holders — the tier and its copies, the application instance during a request, the client's device — and say which of them a delete actually reaches and which it does not.
Show the failover case where an acknowledged delete never reached the copy that got promoted, and say how you would bound the time a signed-out user keeps working.
Decide what the product must promise about sign-out taking effect, and design a revocation signal every authorising path has to consult rather than relying on one entry's absence.
## Sign-out is not one act When per-user state lives on a shared volatile tier, "sign out" looks like a single operation: remove the entry. It is worth being precise about what that removes. A delete is a write like any other. It reaches the node that accepted it, and from there it reaches whatever that store's replication and persistence arrangements reach, when they reach it. Everything else that is holding the same state is untouched, because nothing told it anything. The question a senior candidate is being asked is: enumerate the holders. ## The copies a delete does not reach 1. **Copies inside the tier that have not received it yet.** On stores that acknowledge a write before any copy holds it, there is a window in which the delete exists only on the primary. If that node is lost and a copy is promoted inside the window, the promoted node still has the entry and the user is signed in again. Other stores in this class acknowledge only once a copy holds the write, and some offer that per call — which is why this is a property of your store to establish rather than a universal truth. Where the keyspace is split across nodes, the same reasoning applies per node. 2. **Copies inside the application.** The instance serving the current request has the state in memory already; deleting the entry does not reach into that process. Worse, teams often keep a short-lived local copy precisely to avoid the round trip described elsewhere in this category — every instance that holds one will keep serving the signed-out user until its own copy ages out. 3. **The copy the client holds.** The client has something: at minimum a handle, and in some designs the state itself. That copy sits on a device the operator does not control. No deletion anywhere removes it. Whether it still works is the whole question — and that depends on what the client's copy is. | Copy | Held by | Does the delete reach it? | What actually ends it | |---|---|---|---| | The entry on the node that took the delete | the tier | yes | the delete | | A copy on another node of the tier | the tier | eventually, and not before a failover in the gap | propagation, or acknowledging only after a copy holds it | | The state in a request handler | an application instance | no | the request ending | | A local copy kept to skip the round trip | an application instance | no | the local copy's own short lifetime | | The client's copy | the user's device | no, never | the server refusing to honour it | ## When deleting the entry is genuinely enough Deletion is a perfectly good revocation mechanism under conditions you can state, and a strong answer states them: - every path that authorises a request reads that entry on the tier first, and treats its absence as "not signed in"; - no instance keeps its own copy across requests, or the lifetime of any such copy is short enough to be inside the promise you make about sign-out; - the client's copy is only a handle — it carries no authority by itself, so without the entry it buys nothing; - the tier's copies cannot resurrect the entry, either because there is one node or because a write is acknowledged only after a copy holds it. Break any of those and the absence of an entry is a verdict that some request path never consults. ## Revocation you assert instead of delete Where a copy exists that you cannot delete — a client-held copy that carries the user's identity and privileges itself is the clear case — the design has to invert. Instead of relying on something being gone, give every request path something it must check and that the server still controls, so that "signed out" is a positive answer the server gives rather than an emptiness the caller may never look for. That check has a cost of its own on the request path, and its own staleness where a path caches the answer; both are numbers you choose deliberately. The practical bound on sign-out is then the largest of: how long an application instance may keep a local copy, how far behind the tier's copies may be, and how long the client's own copy remains acceptable. That is the promise you can honestly make to a user who taps "sign out on all devices", and it is worth writing down before someone asks. (It is also the reasoning that makes losing this tier a whole-population event rather than a per-request one — a capacity conversation to have with whoever operates it, in advance.) ## What a weak answer sounds like "We delete the record, so they are signed out." It is not wrong so much as unfinished: it names one holder out of four, assumes propagation it has not checked, and quietly assumes every authorising path consults the tier. The strong answer enumerates the holders, says which deletion reaches, and converts the rest into a bounded number.
- When is deleting the entry genuinely enough on its own?When every authorising path reads that entry on the tier and treats absence as not signed in, no instance keeps a copy across requests for longer than your sign-out promise, the client's copy is only a handle with no authority of its own, and the tier cannot resurrect the entry — one node, or a write acknowledged only once a copy holds it. Those four together make absence a real verdict.
- How do you bound how long a signed-out user keeps working?Take the largest of the numbers you control: the lifetime of any copy an instance keeps locally, the replication lag you tolerate inside the tier, and the lifetime of the client's own copy where that copy carries authority. Each is a number you choose, so the bound is a design output rather than a discovery. Publish it as the promise sign-out actually makes.
Cancelling a visitor in the building's own register does nothing about the key you handed them last week. You can strike their name off your list, but the metal in their pocket still turns the lock, because the lock does not read your list. The building either has to change what the lock consults — make every door check a register it controls, on every entry — or accept that anyone still holding a key gets in until the key stops fitting.
saying these in an interview costs you the question
- Says deleting the entry ends the user's access everywhere, immediately
- Assumes an acknowledged delete has reached every copy whatever the store does
- Forgets an instance may still hold state it read moments earlier
- Believes the server can remove the copy on the client's device
- Treats self-contained client-held state as revoked by deleting a server-side entry
- Calls a missing entry proof of sign-out on a path that never reads the tier