Query about SSE Refresh Behavior

[HiJohnnyLee]

I registered an account and used the online website, and the experience was excellent overall.

I have a question:

When the web page is refreshed, how is a new SSE (Server-Sent Events) request initiated, and how are historical records delivered to the client after the refresh?

Beyond the above execution logic, I would also like to ask for architecture design suggestions for the underlying event bus in this scenario. For example:

• What are the best practices for decoupling the SSE request lifecycle from the event bus?
• How to design the event bus to ensure the consistency and completeness of historical records during page refresh?
• Are there any common architecture patterns (e.g., event sourcing, CQRS) that are suitable for this scenario to optimize the delivery of historical data?

Looking forward to your professional insights and recommendations.

[Mereithhh]

Hi! Thanks for the kind words.

Core Question

Your key question is: How to seamlessly resume an SSE stream after page refresh, and ensure historical data is delivered completely?

Our Approach

1. Dual-Layer Storage

• Hot Layer: During task execution, events are written to a message queue in real-time
• Cold Layer: Final results are persisted to database when task completes

2. Smart Reconnection
When a client reconnects after refresh:

• First check if the task is still running (queue exists)
• If yes → deliver accumulated history as a "snapshot", then continue streaming new events
• If no → fetch complete history from database directly

3. Frontend Auto-Recovery
The client monitors connection health through:

• Tab visibility changes
• Network error detection
• Periodic heartbeat checks

When disconnection is detected, it automatically re-establishes the connection.

Architecture Insights

Decoupling SSE from Event Bus
The producer (task) and consumer (SSE connection) are independent. The task writes events without caring about consumers. Each SSE connection reads independently. If SSE dies, events aren't lost.

Ensuring Consistency
The "fallback to database" pattern is key. The hot layer is ephemeral; the cold layer is the source of truth for completed tasks. This simple heuristic avoids complex distributed coordination.

Applicable Patterns
This is essentially a lightweight Event Sourcing approach:

• Events are temporarily stored during execution
• A materialized "snapshot" (history) is sent on reconnection
• Final state is persisted for long-term storage

A Note on SSE Protocol
The SSE specification itself supports Last-Event-ID header for automatic reconnection. When each event includes an id field, browsers will send this header on reconnection, allowing the server to resume from the exact point. This is a native mechanism worth considering for simpler use cases, though for complex scenarios (like ours with long-running tasks), a custom reconnection strategy often provides more control.

---

Hope this helps! The key insight is: treat the stream as ephemeral, database as durable, and let the client drive reconnection.