WebSockets vs. SSE should be about ordering and correctness

When discussing the choice between WebSockets and Server-Sent Events (SSE) for real-time applications, it is essential to focus on ensuring proper event ordering and maintaining data correctness, rather than simply comparing their performance characteristics. A recent article by Andros, the maintainer of Django LiveView, highlights the advantages of WebSockets, such as reduced payload sizes and the ability to transmit encrypted user data, but argues that these benefits are secondary to the critical issue of event ordering and correctness.

In scenarios where multiple data streams update the same user interface components, receiving and rendering events in the wrong order can lead to confusion for users or even misleading them into making incorrect decisions. For instance, consider an article with tags like "erlang," "clojure," and "javascript," where one user adds the "elixir" tag while another removes the "javascript" tag.

Ideally, the database should reflect a list of "erlang," "clojure," and "elixir," and the user interface should display the same list. However, due to network factors and data delivery timing, the UI might briefly show all tags but ultimately only display "erlang" and "clojure," leaving the user with an inconsistent view of the data.

These issues are not unique to SSE; if two concurrent requests update the same UI element, such as adding and removing tags, a similar race condition can occur. The root cause lies in delivering data over two different streams without proper ordering. While some may argue that "eventual consistency" can resolve this issue, it does not guarantee that the UI will remain up-to-date indefinitely, especially if the user does not refresh the page or if another event does not bring the data back into sync.

To address the challenge of maintaining correct event ordering, WebSockets offer a bidirectional communication channel that can help preserve the correct sequence of updates. This bidirectional nature allows for seamless processing of user events and recomputing updates, ensuring the UI reflects the most current state regardless of the order of events.

Conversely, using SSE with Fetch for handling concurrent updates can lead to data races, as there is no inherent causal ordering between the two streams. One proposed solution is to have Fetch perform updates while SSE is used solely to refresh the UI, but this approach introduces increased latency due to the need for a queue system to manage the updates between servers.

An alternative is to rely solely on SSE to signal the client that new data is available, thereby avoiding the need for additional hops in the server-to-server communication and reducing the server's load. However, this method may increase server load due to the requirement for additional requests to fetch the latest data from the client, especially when concurrent operations are involved.

Moreover, ensuring the correct order of operations on the client side can be complex, as there is no guarantee that events creating or deleting resources will arrive in the expected sequence.

In conclusion, when debating between WebSockets and SSE, it is crucial to consider how to guarantee that events are delivered in the correct order and avoid presenting users with stale or incorrect data. Both technologies have their merits, but ultimately, the choice should be guided by the ability to maintain event ordering and data correctness, especially in scenarios involving multiple concurrent streams of updates.