Context
A live dashboard works during a short demonstration but loses updates after a long session. Another user reconnects successfully and lands in an empty room. WebSockets on Cloud Run are supported, yet an open connection is still a request with a finite lifetime, and a reconnect may reach a different instance. Reliable real-time behaviour therefore belongs partly in the application's protocol and state model.
Expect connections to end
Google documents that WebSocket requests remain subject to the Cloud Run request timeout. Clients need reconnect behaviour, and session affinity is best effort rather than a guarantee of returning to the same instance. The guidance also discusses synchronising data across instances. Review current configuration and limits for your service before selecting connection settings.
A longer timeout can reduce the frequency of expected disconnects, but it does not eliminate network changes, browser suspension, instance replacement, or deployments. Design the product so a connection ending is a recoverable condition. The customer should retain their workflow even when the underlying socket does not survive.
An illustrative collaboration failure
Imagine a shared whiteboard storing room state only in one instance's memory. Two participants initially connect to that instance. After one participant reconnects elsewhere, their board is empty and new drawing events diverge. Enabling affinity may reduce the symptom in a small test without providing a durable state contract.
Identify what must survive a connection and what must survive an instance. Presence information may be temporary, while drawings, chat history, or approved commands may require durable storage. Write these categories into the protocol design so developers do not accidentally use the socket server's memory as the only source of truth.
Define reconnect as a protocol operation
Give the client a supported way to re-establish authentication, identify its session or room, and request missed state. A reconnect should do more than open the same URL again. Decide whether the server returns a current snapshot, events after a sequence, or a combination.
Include bounded backoff and jitter so a service interruption does not cause every client to reconnect simultaneously. Show the user when updates are delayed and when the connection is restored. A silent retry loop can leave someone editing stale information for minutes without realising their changes are not accepted.
Separate commands from notifications
A notification can often be delivered again or replaced by a fresh state snapshot. A command that creates an order or changes a balance needs a stable operation identifier and an acknowledgement contract. The client must distinguish “sent on the socket” from “accepted and durably completed.”
After a disconnect, reconcile uncertain commands using their identifiers. Do not replay every buffered action automatically unless its business semantics support repetition. Consider what happens if the server completes a command immediately before the connection ends and the client never receives the acknowledgement.
Synchronise instances deliberately
Choose a shared distribution mechanism for events and a durable store for state where required. These may be different systems with different delivery guarantees. A pub/sub broadcast helps instances hear updates, while a database or event log may be needed to recover missed history.
Review ordering, duplication, and subscription recovery in the shared mechanism. If an instance misses a broadcast during restart, it must still be able to serve correct state afterward. Avoid treating a transient event bus as a permanent history unless it was explicitly configured and operated for that purpose.
Size for long-lived requests
Persistent connections affect concurrency and resource use differently from short API calls. Measure memory per connection, message frequency, fan-out, and the work performed for each message. Include slow clients and large rooms in testing.
Set application-level limits on message size and queued outbound data. A slow browser should not cause an unbounded memory queue in the server. Define whether the server disconnects a lagging client, drops replaceable updates, or requires it to resynchronise. The correct choice depends on whether the data is a notification stream or an authoritative event sequence.
Rehearse the real failure sequence
Keep a client connected across the configured request lifetime and confirm it reconnects. Deploy a new revision while clients are active. Then terminate a test instance or disrupt connectivity and verify recovery on another instance with the correct state.
Test two clients viewing the same entity and a client returning after a longer absence. Compare accepted commands and visible state, not just connection counts. Include token expiry during reconnect so the system does not restore a room using an expired or inappropriate authorisation context.
Quick diagnostic map
| Evidence | Interpretation | Next check |
|---|---|---|
| Reconnect reaches empty room | State remained instance-local | Read shared history |
| Commands execute twice | Lost acknowledgement replayed | Reconcile operation identity |
| Memory grows with clients | Outbound buffering unbounded | Inspect slow consumers |
A focused operator exercise
Open two clients in the same synthetic room and record their last accepted event sequence or snapshot revision. Keep the clients connected across the configured request lifetime, then deploy a replacement revision. Confirm reconnects can reach another instance and recover the same shared state without relying on memory in the retired process.
Submit a command with a stable identifier and interrupt the connection before its acknowledgement reaches the client. Reconnect and query or reconcile that identifier before resubmitting. Verify the accepted business action occurs according to the intended idempotency contract. Test a slow client as well, ensuring outbound buffering remains bounded and the resynchronisation policy is visible.
Include authentication expiry and a period in which shared event distribution is unavailable. The interface should report delayed updates or recovery rather than appearing silently current. The exercise passes when users regain accurate state, uncertain commands have explained outcomes, and operators can correlate connection loss, instance change, and application recovery in one concise incident record.
Observe user-visible continuity
Monitor disconnect reasons, reconnect success, resynchronisation duration, missed-event recovery, and uncertain command reconciliation. Correlate these with deployment events and instance scaling. A stable connection graph is less important than whether users retain accurate state and receive acknowledged results.
Clouvenix can help review Cloud Run configuration alongside the WebSocket protocol and shared state design. The outcome is a real-time service that can recover naturally when the connection or serving instance changes.
Frequently asked questions
Does session affinity remove the need for shared state?
No. Affinity is best effort, and the chosen instance can disappear. Keep the state needed for recovery somewhere the replacement instance can access, and give clients a defined resynchronisation operation after reconnecting.
Should the client resend every unacknowledged message?
Only according to the message's contract. Notifications, edits, and payment commands have different semantics. Use stable command identifiers and query the accepted result when the previous outcome is uncertain, rather than assuming a disconnect means the command failed.
Explore Clouvenix custom application development for implementation and operational handover.