Session architecture for a multi-provider platform

A platform that publishes listings can also open titles that live with other providers. One implementation stored an opened title as a folder of files. The provider’s handle expired, and the folder still looked full. A person came back to the tab and met assets that could no longer be started, with no record of when the session had ended. Store a clock instead.

The record

A session record carries a small set of fields.

• The platform’s session id.
• The provider id and the title id, using the noun in How multi-provider API integrations work.
• The moment the session started.
• The idle limit the platform promised, as a duration.
• The moment the session ended, once it has ended.
• The reason it ended: the person left, the idle limit ran out, the provider rejected the handle, or the platform closed it.

Scoring, prices, and the title’s internal rules stay with the provider. The platform can say who opened which title, when, and why the session stopped.

The handoff

Opening is a short exchange. The platform asks the provider to open a title for this session. The provider returns a handle and the moment that handle expires. The platform shows the title inside the session and watches the earlier of two times: the handle’s expiry, and the platform’s idle limit. When either arrives, the session ends and the reason is written down. A later visit starts a new session and asks for a new handle.

Playable titles

One provider publishes playable titles, games, into the catalog beside ordinary listings. The catalog entry carries the same noun as any other title: an identity, a display name, a status. The session record stays one shape. The handoff is what changes. That provider returns a handle that starts play, and the provider keeps score, progress, and the rules of the title. The platform keeps the clock and the catalog entry. The provider remains the publisher of the game.

Another provider is added by mapping its identifiers into the shared noun, and by giving it a place on the timetable in API orchestration for a B2B platform. The clock stays one shape unless a provider’s idle rule truly differs. When it does, the session record stores that provider’s duration, with the reason written beside it.

A clock, not a folder

The folder of files looked full after the provider’s handle had expired. A person returned to the tab and met assets that could no longer be started. Nothing on the screen said the session had ended, or why. Store the start, the idle limit, the end, and the reason. The files, if the title needs them, stay with the provider and are asked for again with a new handle.

Read a stored session by its end. If the end is empty, the session is still open, and the page should be watching the earlier of the handle’s expiry and the platform’s idle limit. If the end is filled, the next visit does not reuse the handle. It starts a new session and asks again.

Score stays with the provider

Scoring, prices, and the title’s internal rules stay with the provider. The platform can say who opened which title, when, and why the session stopped. It cannot reconstruct a score from a folder it should not have copied. A playable title makes this sharper. The provider returns a handle that starts play and keeps score, progress, and the rules. The platform keeps the clock and the catalog entry. The catalog entry is still the shared noun: an identity, a display name, a status. The session record does not grow a field for the score.

Two times, and the earlier one wins

The provider says the handle expires at one moment. The platform promised an idle limit, a duration, from the start. The session ends at the earlier of those two. Write the reason that matches the one that won: the handle was rejected or expired, or the idle limit ran out, or the person left, or the platform closed it. A single reason of “ended” makes the next investigation guess.

If one provider’s idle rule truly differs, store that duration on the session and write the reason beside it. Do not fork the whole record into a second shape for that provider. A second shape is how the folder comes back, under a new name.

Opening, in one exchange

The platform asks the provider to open a title for this session. The provider returns a handle and the moment the handle expires. The platform shows the title inside the session. When the earlier clock arrives, the session ends, the reason is written, and the handle is discarded. A later visit is a new session. There is no “resume” that skips the ask. Resume, in this design, was the full folder with a dead handle.

The listing noun those identifiers come from is How multi-provider API integrations work. The calls that are allowed to run before anything is public are the timetable, not this clock. The clock starts only after a person opens a title the catalog already decided to show.

The record is four times and two ids

Write the session down as fields before you write the call. Start. Idle limit, a duration from the start. End, empty while the session is open. Reason, empty until the end is filled. Provider id. Title id. Those last two come from the listing noun, the same identity the desk already uses. Do not invent a session-only name for the title. A second name is how the folder of files sneaks back, under a label that sounds new.

If the end is empty, the session is open, and the page should be watching the earlier of the handle’s expiry and the idle limit. If the end is filled, the next visit does not reuse the handle. It starts a new session and asks again. There is no third state called “paused” unless you can say what paused means for the handle. A paused session that keeps a dead handle is the folder, renamed.

Score, progress, and the title’s own rules are not fields on this record. The provider keeps them. The platform can say who opened which title, when, and why the session stopped. It cannot rebuild a score from a copy it should not have made. A playable title makes this sharper, because the provider returns a handle that starts play and keeps the score. The platform keeps the clock and the catalog entry. The catalog entry is still the noun: identity, display name, status. The session record does not grow a score field “just for this provider.”

Two clocks, and the sentence that matches the winner

The provider says the handle expires at one moment. The platform promised an idle limit from the start. The session ends at the earlier one. The reason names the winner: the handle was rejected or expired, or the idle limit ran out, or the person left, or the platform closed it. A reason of “ended” makes the next look a guess. Write the four reasons as the only vocabulary, and add a fifth only when a weekday produces a fifth way to stop.

If one provider’s idle rule truly differs, store that duration on the session and write the reason beside it. Do not fork the whole record into a second shape. A second shape is the folder returning. The fields stay the fields. Only the duration number changes, and the number is visible next to the reason so a person can see why this session’s idle limit was not the platform’s usual one.

Show the end and the reason on the desk when a session stops. A session that vanishes from the list with no row has not stored a clock. It has deleted the evidence. The row can leave the public catalog. It stays on the desk long enough for someone to read the reason.

Opening is one exchange, and resume is a new one

The platform asks the provider to open a title for this session. The provider returns a handle and the moment the handle expires. The platform shows the title inside the session. When the earlier clock arrives, the session ends, the reason is written, and the handle is discarded. A later visit repeats the ask. Resume, in the design this plate retires, skipped the ask and opened a stored folder. The folder outlived the handle. The person met assets that would not start, and nothing on the screen said the session had ended.

Do not keep the handle “in case they come back in a minute.” The idle limit is that minute, already. If they return inside the idle limit, the session is still open and the handle is still the one you were given. If they return after, you ask again. A cache of the last handle is a small folder. Treat it as one.

The timetable does not run this clock. The timetable’s job is to refuse a public listing the provider has withdrawn, before a person can open it. The clock starts only after a person opens a title the catalog already decided to show. If you start a session for a listing the timetable has not accepted, you are storing a clock for a title the desk is not willing to name. Finish the noun and the timetable first. Then the four times and the two ids are enough.