Why Real-Time Is Now a Table-Stakes Feature for SaaS Products

Users who have experienced real-time collaboration in Figma, live dashboards in Datadog, or instant notifications in Slack have raised their expectations for all SaaS products. “Refresh the page to see updates” is no longer acceptable for any product handling data that changes frequently. Real-time features, live updates, collaborative editing, instant notifications, live dashboards, are now expected in B2B SaaS, not differentiating. The architectural challenge is building these features reliably at scale without creating brittle systems that fail under load or consume excessive infrastructure resources. Our SaaS Development team has built real-time systems handling millions of concurrent connections and hundreds of thousands of events per second.

WebSockets vs Server-Sent Events: The Technical Decision

WebSockets and Server-Sent Events (SSE) are both mechanisms for server-to-client real-time communication, but they have important architectural differences:

• WebSockets: A persistent, full-duplex TCP connection. Both client and server can send messages at any time. Required for use cases where the client must send frequent messages to the server (collaborative editing, multiplayer games, chat). Higher infrastructure complexity: WebSocket connections are long-lived and stateful, requiring sticky sessions or a connection registry in distributed deployments.
• Server-Sent Events: A one-way, server-to-client stream over standard HTTP. The client subscribes to an EventSource endpoint, and the server pushes events as they occur. Simpler to implement, works over HTTP/2, and automatically reconnects on connection loss. Sufficient for most SaaS real-time use cases: live dashboard updates, notification feeds, background job progress, and activity streams.

The decision rule: if your real-time feature requires the client to send frequent messages (more than once per second), use WebSockets. For everything else, SSE is simpler and more scalable. Our Website Development team defaults to SSE for most SaaS real-time features and uses WebSockets only when genuinely required.

Pub/Sub Architecture: The Backend for Real-Time

Real-time frontend features require a pub/sub (publish/subscribe) architecture on the backend. When an event occurs (a record is updated, a job completes, a message is sent), a publisher emits an event to a channel. Subscribers, typically WebSocket or SSE connection handlers for specific users or rooms, receive the event and push it to connected clients. Redis Pub/Sub is the most common choice for SaaS applications: fast, simple, and sufficient for most workloads. For higher throughput, Apache Kafka provides durable event storage (events can be replayed), consumer groups, and horizontal scaling. For managed infrastructure, Ably, Pusher, or AWS API Gateway WebSocket APIs reduce operational complexity at the cost of higher per-message pricing. Our SaaS Development team selects the right pub/sub infrastructure based on message volume, durability requirements, and operational capacity.

Collaborative Editing: The Most Complex Real-Time Feature

Collaborative document or data editing, multiple users editing the same record simultaneously, is the most architecturally complex real-time feature. The core challenge is conflict resolution: when two users edit the same field simultaneously, whose change wins? Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs) are the two established approaches. CRDTs, implemented by libraries like Yjs and Automerge, are the modern choice: they allow disconnected clients to make changes that are merged deterministically when they reconnect, with no central server required to adjudicate conflicts. Yjs integrates with ProseMirror, TipTap, and Quill for rich text collaboration, and with custom data structures for non-text collaborative editing. For SaaS products requiring collaborative forms, shared spreadsheets, or collaborative workflow editing, CRDTs provide the foundation. Contact our Software Flux Solution team to discuss collaborative editing architecture.

Scaling Real-Time: Connection Management at High User Counts

A single Node.js process can maintain approximately 10,000 concurrent WebSocket connections before memory and CPU become limiting factors. A SaaS with 100,000 concurrent users requires 10+ connection handler processes, plus a mechanism for routing events to the correct process. When a user in Process 1 sends a message to a user connected to Process 3, the pub/sub layer (Redis) routes the event correctly. This is the horizontal scaling pattern for real-time systems, and it works well up to millions of concurrent connections. Beyond that, dedicated real-time infrastructure (Ably, Stream, or a custom Elixir/Phoenix cluster using its built-in channels system) is more cost-effective than scaling general-purpose Node.js servers. Our Blog covers real-time scaling architecture in depth, or Contact Us us to discuss your specific scaling requirements.