Replay Buffer Optimization

Status: Draft Author: Ryan Nel Date: 2026-05-01

Problem

Core's WebSocket replay buffer retains the last 5 minutes of durable events per user. If the client reconnects after the buffer expires, Core sends a ReplayExpiredEvent and the client must do a full state re-fetch via REST. For a 2-hour meeting with thousands of transcript segments, hundreds of talking points, and dozens of tasks, this full re-fetch is expensive — both in latency and server load.

The current design uses a full refresh on replay expiry. This is acceptable for v1 because reconnects beyond 5 minutes are expected to be rare during active recording sessions (the OPFS buffer and automatic reconnect cover most short outages). However, as session lengths grow and the product adds more real-time state, the cost of full re-fetch will increase.

Appetite

1–2 weeks. Potential approaches include: extending the replay buffer TTL, including last_known_version per entity type in ReplayExpiredEvent to enable incremental fetches, or a cursor-based catch-up mechanism that fetches only events the client missed.

Why Now

This problem was identified during the design review of the Meeting Recording bet and deferred deliberately. The full-refresh approach is sufficient for v1. It should be revisited if monitoring shows that replay-expired reconnects are common or that the full re-fetch causes measurable latency or load.