Speedway Technology · Realtime Operations
Realtime makes change visible quickly. Durable state makes it recoverable.
Speedway uses realtime transport to move operational change rapidly across connected applications, but a live connection is never treated as the sole record of what happened. Foreground delivery sits above canonical state, durable event history and explicit recovery paths so a sleeping device, roaming network or missed message can resynchronize instead of guessing.
Current architecture
A persistent realtime session sits above the physical transport.
Speedway's foreground realtime layer is an authenticated connected session for low-latency event delivery. It uses short-lived credentials, channel-scoped delivery, reconnect backoff and history-backed recovery. The transport is not the authority for business state; durable platform state remains authoritative.
Short-lived credentials establish the connected realtime path. Channel-scoped delivery keeps operational events within the permitted session boundary.
Recoverable channel history and automatic reconnect help the foreground session resume after brief interruption instead of treating every reconnect as a fresh state boundary.
When the primary connection is unavailable, SSE carries downstream events while authenticated HTTP requests carry acknowledgements and user actions upstream. SSE itself remains one-way; Speedway emulates bidirectional application behaviour above the transport by pairing the downstream stream with authenticated HTTP upstream actions.
Cursor-based replay, duplicate-safe consumption and durable polling provide a second recovery path. Canonical resynchronization remains the final correctness boundary when a stream is incomplete or unavailable.
The event path
A realtime message follows a governed state change; it does not replace the state-changing decision.
The Single Operating Record keeps authority at the capability boundary. Realtime delivery lets other participants react quickly after the authoritative change or event has been accepted.
The owning service validates a protected mutation or records a governed operational event according to its business rules.
Authorized participants can be notified that relevant operational state or history has changed.
A connected application can update a projection, refresh a bounded object or present a notification to the appropriate participant.
If the foreground event is missed, the participant can later retrieve current canonical state or the durable history needed to rebuild its projection.
Reconnect and resynchronization
A reconnect is a recovery boundary, not proof that nothing changed while the participant was away.
Mobile devices sleep, browsers suspend background work and networks change underneath active sessions. Speedway therefore treats reconnect as an opportunity to establish current state rather than simply reopening a socket and assuming the previous event sequence was complete.
The participant can recognize that its foreground connection was interrupted or that its local projection may be stale.
The preferred stream can be re-established when available without treating reconnection itself as sufficient synchronization.
The participant can request the current governed object or relevant durable changes needed to restore a trustworthy local projection.
Once the projection is synchronized, foreground events again accelerate subsequent changes.
Duplicate and ordering safety
Event consumers should tolerate retry and recovery without turning transport behavior into repeated business effects.
Realtime delivery is a communication mechanism. Consumers should use event identity, object revisions or capability-specific guards so duplicate delivery, delayed delivery or reconnect recovery does not accidentally become a second protected mutation.
Where a consumer initiates downstream work, the logical identity of the operation can prevent repeated delivery from producing repeated business effects.
A surface can compare the current governed object or revision rather than trusting arrival order as the sole definition of truth.
A realtime message can identify what changed without embedding unnecessary protected state or granting the transport authority over the business object.
If ordering or completeness is uncertain, a fresh canonical read is safer than inferring missing business state from the stream alone.
Offline-first relationship
Realtime and offline-first architecture solve complementary problems.
Realtime improves the connected experience; offline-first operations preserve useful local work and make reconnection recoverable. Neither should be asked to substitute for the other.
Realtime transport minimizes the delay between a governed change and a participant seeing that change.
Local state and queued intent let permitted workflows continue when no foreground transport is available.
Queued local changes and missed remote changes are reconciled through the canonical capability owner rather than merged by transport arrival order.
After durable synchronization, realtime delivery resumes as the accelerator for subsequent operational changes.
Degraded mode
A realtime outage should reduce immediacy before it reduces correctness.
The fallback hierarchy is designed so a problem with foreground event delivery can be isolated from protected state. Applications may refresh less quickly or use polling while the streaming path is degraded, but they should still have a route to current canonical truth.
Use the split fallback path: SSE for downstream event delivery and authenticated HTTP for upstream acknowledgements and actions, without changing which service owns the underlying operational object.
Use durable polling or explicit refresh so critical operational state remains recoverable.
Use local-first state and synchronization queues according to the workflow's offline policy.
Fail toward canonical resynchronization and visible uncertainty rather than presenting a stale projection as definitive.
Public architecture boundary
The transport model is public; private topology and security configuration are not.
This article establishes Speedway's realtime architecture and transport contract without publishing internal hosts, private channels, credentials, signing material, network topology or deployment-specific security configuration.
Authenticated realtime sessions, channel-scoped delivery, automatic reconnect, history-backed recovery, split-path SSE/HTTP fallback, cursor replay, durable polling, state reconciliation and duplicate-safe consumption.
Private endpoints, infrastructure addresses, credentials, channel authorization internals, security policy and deployment-specific transport configuration.
Realtime & Recovery