real-time-systems-architect

Use SSE with a Next.js route handler that subscribes to BullMQ QueueEvents and pushes progress, completed, and failed events to the client. The client consumes the stream with EventSource and reconnects with exponential backoff on errors.

Choose SSE when data flows server-to-client only, such as job progress or dashboard metrics, since it works over HTTP/2 and through reverse proxies. Use WebSocket only when the client also sends events, like presence heartbeats or collaborative editing.

Reconnect with exponential backoff capped at 30 seconds, then reconcile state using version-stamped server data. Never trust local client state after a disconnect; fetch the server state and apply it if its version is newer.

Yes, but you must set the X-Accel-Buffering: no header to disable proxy buffering and send a keep-alive ping every 15 seconds to prevent proxy timeouts. SSE also simplifies auth since it uses standard cookies over HTTP.

Use a bounded broadcaster where each subscriber has a capped queue. When a subscriber's queue fills, drop the oldest event and log the overflow, so one slow consumer never blocks producers or other subscribers.

Avoid WebSocket for unidirectional flows like metrics dashboards or job progress, where SSE is simpler and proxy-friendly. WebSocket adds connection management overhead that is only justified for bidirectional communication.