Q267: WebSocket SSE Realtime Security and Resilience

What Interviewers Want To Evaluate

Interviewers want to know whether you can design realtime frontend connections safely.

They want to hear the trade-offs between WebSocket and Server-Sent Events, plus authentication, reconnection, backpressure, message validation, ordering, and observability.

Short Interview Answer

WebSocket provides bidirectional realtime communication, while Server-Sent Events provide server-to-client streaming over HTTP. For secure realtime systems, I authenticate the connection, authorize every channel or subscription, validate message schemas, handle reconnects with backoff, avoid infinite replay, protect against overload, and design clear UI states for connecting, stale, live, and disconnected. Realtime is not only transport; it is a state synchronization problem.

Detailed Interview Answer

Realtime features can include:

chat
notifications
collaboration
live dashboards
progress updates
deployment logs
presence
AI streaming

The transport matters, but the state model matters more.

You need to know:

who may connect?
what may they subscribe to?
what messages are allowed?
what happens after reconnect?
how are duplicates handled?
how is stale UI shown?

WebSocket

WebSocket starts as an HTTP upgrade and becomes a persistent bidirectional connection.

It is useful when both client and server need to send messages independently.

Examples:

collaborative editing
multiplayer interactions
live chat
presence updates
bidirectional device control

Security does not end after connection.

Each message still needs validation and authorization.

Server-Sent Events

SSE is server-to-client streaming over HTTP.

It is simpler than WebSocket for one-way updates.

Good use cases:

notifications
live logs
AI token streaming
build progress
read-only dashboards

The browser has built-in EventSource, but custom headers are limited.

Authentication strategy must account for that.

Authentication

Realtime authentication may use:

secure cookies
short-lived connection tokens
Authorization headers where supported
signed subscription tokens
server-side session lookup

Avoid putting long-lived tokens in URLs because URLs may appear in logs, browser history, proxies, or analytics.

If a token must be in a URL, keep it short-lived and scoped.

Authorization

Do not authorize only the connection.

Authorize subscriptions and messages.

Example:

user can connect
user can subscribe to room 123
user can send message to room 123
user cannot subscribe to room 999

This prevents cross-tenant leaks.

Message Validation

Every message is runtime input.

Validate:

type
version
payload shape
size
sender permissions
sequence or timestamp
idempotency key

Ignore unknown message types safely.

Never trust a client message because it came through an authenticated socket.

Reconnection

Connections fail.

Use:

exponential backoff
jitter
maximum retry delay
visibility-aware reconnect
network online/offline events
manual retry

Avoid reconnect storms when many clients disconnect at once.

State Recovery

After reconnect, the client may have missed events.

Recovery strategies:

fetch latest snapshot
resume from last event ID
server replay window
idempotent event application
conflict resolution

The UI should not silently pretend it is current while disconnected.

Backpressure

Realtime systems can overwhelm the browser.

Symptoms:

message queue growth
main-thread jank
memory increase
missed frames
stale UI

Mitigate with batching, throttling, dropping low-value events, virtualization, and server-side filtering.

Interview Example

If asked, "Would you use WebSocket or SSE for build logs?"

Answer:

"For one-way build log streaming, SSE may be enough and simpler operationally. I would use WebSocket only if the client also needs to send frequent commands over the same connection. Either way, I would authenticate the stream, authorize the build ID, support reconnect from the last event, and show stale or disconnected states."

Common Mistakes

Common mistakes include:

authorizing only connection but not channel access
putting long-lived tokens in URLs
no reconnect backoff
no stale state in UI
trusting message payloads
not handling duplicate events
not bounding message size
not measuring client memory or jank

Senior-Level Framing

The senior framing:

"Realtime is a secure state synchronization problem. I choose WebSocket or SSE based on directionality, then design authentication, authorization, schema validation, recovery, backpressure, and UX states."

Practice Prompt

Design realtime updates for:

live study reminders
AI answer streaming
collaborative notes
deployment build logs
admin incident dashboard

For each, choose WebSocket or SSE and define auth, reconnect, recovery, and UI states.

Final Mental Model

Realtime connections make applications feel alive.

They also keep risk alive for longer.

Secure them as long-running contracts, not one-time requests.