SSE — Server-Sent Events | One-Way Real-Time Communication

Server-Sent Events (SSE) is a technology that allows a server to continuously send updates to a client over a long-lived HTTP connection.

The important difference is that communication is primarily server → client.

1. How SSE Works

The client establishes an HTTP connection with the server. The server keeps the connection open and sends events whenever new data is available.

sequenceDiagram
Client->>Server: Open SSE connection
Server-->>Client: Event 1
Server-->>Client: Event 2
Server-->>Client: Event 3
Server-->>Client: Event 4

2. SSE Is One-Way

SSE is designed primarily for the server to push updates to the client.

flowchart LR
Server --> Client

If the client needs to send data to the server, it can use a normal HTTP request separately.

flowchart LR
Client -->|HTTP Request| Server
Server -->|SSE Events| Client

3. SSE Example

Consider a live notification system.

sequenceDiagram
Client->>Server: Subscribe to notifications
Server-->>Client: Notification 1
Server-->>Client: Notification 2
Server-->>Client: Notification 3

The client does not need to repeatedly ask whether a new notification is available.

4. SSE vs Long Polling

5. SSE vs WebSocket

6. SSE vs SignalR

SSE is a communication technology for server-to-client event streaming. SignalR is a higher-level real-time framework that can use multiple transports, including SSE. Your reference material specifically lists SSE as one of the transports available to SignalR. :contentReference[oaicite:1]{index=1}

flowchart TD
SignalR["SignalR"]
SignalR --> WebSocket["WebSocket"]
SignalR --> SSE["Server-Sent Events"]
SignalR --> LongPolling["Long Polling"]

7. When Is SSE Useful?

SSE is useful when the main requirement is continuous server-to-client updates.

• Live notifications
• Live dashboards
• Monitoring updates
• Live status changes
• Streaming textual events

8. SSE Example Architecture

flowchart LR
Client["Browser"]
API["ASP.NET Core API"]
Service["Business Service"]
Database["Database"]

Client -->|SSE Connection| API
API --> Service
Service --> Database
API -->|Events| Client

The server can send an event to the connected client whenever relevant information changes.

9. SSE and ASP.NET Core

An ASP.NET Core application can expose an HTTP endpoint that keeps the response open and writes events as they become available.

[HttpGet("events")]
public async Task Events()
{
    Response.ContentType = "text/event-stream";

    while (!HttpContext.RequestAborted.IsCancellationRequested)
    {
        await Response.WriteAsync(
            "data: New update\n\n");

        await Response.Body.FlushAsync();

        await Task.Delay(1000);
    }
}

The important idea is that the HTTP response remains open while the server sends events.

10. SSE in a Scaled Application

In a system with multiple application servers, SSE connections may be distributed across different instances.

flowchart LR
Client1["Client 1"] --> LB["Load Balancer"]
Client2["Client 2"] --> LB

LB --> Server1["API Server 1"]
LB --> Server2["API Server 2"]

If events are generated by different services or servers, shared messaging infrastructure may be needed so that connected clients receive the appropriate updates.

11. Advantages of SSE

• Simple server-to-client streaming model.
• Uses HTTP.
• Suitable for continuous server push.
• Useful for browser-based applications.

12. Limitations of SSE

• Primarily one-way communication.
• Not designed for full bidirectional communication.
• Long-lived connections need to be considered when scaling.
• WebSocket is more appropriate when both sides need frequent real-time communication.

13. Quick Comparison

14. Important Interview Questions

• What is SSE?
• How does Server-Sent Events work?
• Is SSE one-way or bidirectional?
• SSE vs WebSocket?
• SSE vs Long Polling?
• SSE vs SignalR?
• When would you use SSE?
• How would you scale SSE?

Key Takeaways

• SSE provides server-to-client event streaming.
• SSE uses a long-lived HTTP connection.
• The server can continuously push events to the client.
• It is useful when communication is primarily server → client.
• WebSocket is better suited for bidirectional real-time communication.
• SignalR can use SSE as one of its supported transports.

Conclusion

SSE is a simple approach for applications where the server needs to continuously push updates to clients over HTTP.

Long Polling → Wait for one response

SSE          → Continuous Server → Client events

WebSocket    → Continuous Client ↔ Server communication

SignalR      → Higher-level real-time framework