The alert says “consultation room messages rejected.” The on-call view shows a clinician still connected to video, a patient whose chat bubble spins, and a retry counter climbing every second. That is a message-size failure, not a media failure, and treating it as one creates a very expensive incident.
Short answer: enforce a small, explicit envelope at every hop, reject oversized messages before they enter a queue, and make the client recover with a resumable event log rather than blind retries. WebRTC data channels, WebSocket gateways, and your application bus can all have different limits, so the smallest limit in the path is the real contract.
What should a realtime message limit protect in a video consultation room?
Start with the message classes. Presence, typing, device status, and a “clinician joined” event are tiny and frequent. A transcript delta or an attachment descriptor is larger and less frequent. The video itself belongs on the media path; sending a frame or a base64 recording through the control channel is a design error.
For a healthtech room, the limit protects more than memory. It bounds parsing time, queue depth, audit payload size, and the blast radius of a malformed client. Pick a byte ceiling for the encoded envelope, document it in the protocol, and reserve headroom for fields added later. JSON character count is not a byte count: UTF-8 names and translated text make that mistake visible at the worst moment.
The alert should fire on the signal that precedes user pain. Track rejected bytes and rejected messages by room, message type, and client version; also track queue age and reconnect duration. A useful SLO is “99.9% of control events are acknowledged within one second,” paired with a separate availability target for media. One aggregate latency chart hides the distinction.
How do realtime size limits change failure handling and reconnect backfill?
An oversized event should be a terminal client error for that event, not an invitation to retry the same payload. Return a typed error such as message_too_large, include the negotiated limit, and keep the socket usable for smaller control messages. If the event is important, store a compact reference and let the receiver fetch the detail over an authenticated HTTPS endpoint.
Reconnect is where the implementation either earns its keep or loses the room. Assign every event a monotonically increasing sequence, persist a short replay window, and let a reconnecting client present its last acknowledged sequence. The server sends the missing events, then resumes live delivery. If the gap is older than the replay window, send a snapshot followed by new events; do not replay an unbounded history into a newly recovered browser tab.
Keep it boring.
Here is the shape of a Go gateway check. The limit is applied after JSON encoding, so the check measures what actually crosses the wire.
package gateway
import (
"encoding/json"
"errors"
)
var ErrMessageTooLarge = errors.New("message_too_large")
type Envelope struct {
Seq uint64 `json:"seq"`
Type string `json:"type"`
Data interface{} `json:"data"`
}
func EncodeWithinLimit(e Envelope, limit int) ([]byte, error) {
b, err := json.Marshal(e)
if err != nil {
return nil, err
}
if len(b) > limit {
return nil, ErrMessageTooLarge
}
return b, nil
}
The surrounding handler must still apply authorization, schema validation, and rate limits. A size check is not validation. In one review, a team had a generous gateway limit but a smaller broker frame limit; the gateway accepted the event, the broker rejected it, and the client retried until the room's queue filled. The first dashboard symptom was a chat delay, so the incident was initially filed as a browser performance issue. Looking at queue age, then rejected-byte counters, showed that a transcript delta was being encoded twice by one client version. Because the error was not typed, the sender treated it like a transient network loss and sent the same payload on every reconnect. We changed the contract to return message_too_large, stopped retries for that code, and recorded the last acknowledged sequence in the room log. The fix was a single published limit plus an integration test that exercised the complete path, including a reconnect with a full replay window and a payload containing multibyte UTF-8 text.
False positives have a cost. A limit that is too low drops legitimate translated notes and causes needless snapshot fetches; a limit that is too high lets one bad room consume parser and queue capacity. I would start from observed p99 payload size, add explicit protocol headroom, and revisit it after a week of production histograms. I'm not sure a universal number exists, because language, locale, and attachment metadata vary; your mileage may vary, but the measurement method should not.
Buy, build, or split the realtime path?
The decision is about failure ownership, not a price slide. A managed realtime relay can reduce the amount of reconnect machinery your team operates, while a self-hosted gateway gives you direct control over limits, retention, and audit boundaries. A split design keeps media on WebRTC and sends only compact control events through a separately operated channel.
| Option | Strength | Catch | Choose it when |
|---|---|---|---|
| Managed relay | Less connection and regional capacity work | Limit and replay semantics may be provider-specific | Your team lacks 24/7 realtime operations |
| Self-hosted WebSocket gateway | Full policy, logs, and schema control | You own fan-out, backfill, and patching | Audit and custom recovery rules dominate |
| Split media/control paths | A large video payload cannot starve control events | Two observability and deployment surfaces | Video continuity and chat reliability have separate SLOs |
Do not choose on unit price alone. Count on-call pages, replay storage, egress, compliance review, and the engineering time required to test reconnect storms. Stick with a managed relay when its documented maximum and replay behavior fit the measured envelope; build the gateway when those semantics are a hard clinical requirement. The unsuitable case is a vendor whose limit cannot be negotiated or observed, because you cannot explain a dropped care instruction to an auditor.
A practical alert-to-action loop
The page should link to a room sample containing the rejected message type, encoded byte size, client version, and last acknowledged sequence. The first action is to confirm whether the rejection rate is isolated to one schema revision or locale. Next, compare queue age and reconnect duration against the control-event SLO. Finally, inspect whether the sender is retrying a terminal error.
That sequence works for a device-status dashboard as well as a consultation room: a device update can be compacted, acknowledged, and backfilled without touching the video stream. Instrumentation closes the loop when the threshold is wrong. If the alert fires for harmless oversized transcript drafts, lower the severity and fix the client boundary; if a small event is rejected, treat it as a contract regression.
References
- https://www.w3.org/TR/webrtc/
- https://www.rfc-editor.org/rfc/rfc6455
- https://www.rfc-editor.org/rfc/rfc8445
- https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
Top comments (0)