Staying logged in

At 10:01, nerves win. Case closes the app entirely, stares out the window, and opens it again.

It comes back signed in, mid-thought, exactly where it was. No password asked. The app knows Case, and it is worth one scene of this morning to ask how, since the app was just now fully dead.

The ticket and the coat

When Case first signed in, weeks ago, Traversal handed the phone a small token of recognition and asked it to hold on. On the web that token is usually a cookieConcept · lights on your mapcookieA small piece of information a website asks the browser to store and send back with matching future requests. The mechanism behind staying signed in, governed by rules about domain, lifetime, and who may read it.: a slip the browser presents with every later request, so identity survives between visits.

What the slip points to is a sessionConcept · lights on your mapsessionA period of interaction during which an application remembers who you are and where you were. Commonly the cookie carries a session identifier and the server keeps the substance, like a coat-check ticket and the coat. Logging out tears up the ticket.. The ticket is on the phone. The coat, everything Traversal remembers about signed-in Case, stays on the backend. Case carries the small thing, Traversal keeps the heavy thing, and the arrangement is why a dead app can rise knowing your name.

Where the remembering lives

All of it together, the half-filled form, the signed-in-ness, which screen was open, is application stateConcept · lights on your mapapplication stateInformation describing an application’s current condition. It lives on both sides at once: the client holds its working copy, open screens and unsent typing, while the server holds the authoritative version., the same idea Act 0 called state, now visibly split across the seam from two scenes ago. The phone keeps a working copy so the app feels instant. The backend keeps the version that counts.

Servers keep working copies too, for speed. A backend’s store of answers it worked out recently is a cacheConcept · lights on your mapcacheA store of data or previously computed results a system keeps so it can reuse them instead of repeating expensive work. Speed, traded against freshness: the stored copy can fall behind the truth., and the trade it makes is always the same one. Speed now, staleness risk later.

The two minutes, explained

Now the scene from the start of this story can finally be taken apart. Weeks from this morning, at 6:04 on lottery day, Case’s app will say pending while an email says congratulations. Act 0 told you which copy to believe. What it could not yet give you is the machinery’s names.

You can name it now. The app was showing its working copy of application state, fetched the evening before, and the truth had moved at 6:02. The email came straight from the fact. The screen came from a copy of the fact, and a copy is a thing that was true when it was made. Pull down to refresh was Case demanding a fresh copy, and the two minutes of disagreement were nothing breaking and everything working, each half honestly reporting what it knew.

One mystery down. The morning has one more in it, hiding behind the Pay button, and this act ends there — the button cannot be pressed until the doors have names.