Live Caption Room Delivery: Segment Timing and Reconnect Recovery

Live caption delivery requires stable ordering and timing for each segment, even when reconnecting. Pack captions as domain events with a unique ID containing room, session, source, sequence, start/end offsets, text, and interim status. Raw bytes may be small, but account for object count, write operations, replication, and indexes.

For 40 rooms, four segments per second, 350 bytes per event, eight active hours, and 30 days of retention, expect about 48.384 GB of raw events and 138.24 million event records before storage considerations.

Publish events to a partitioned log, compact finalized captions into minute-scale objects, and keep final segments plus a short correction window. Discard interim hypotheses after the correction window, unless legal replay requirements dictate otherwise. Treat captions as events, not strings, and include a stable event ID for retries. Use a monotonic sequence per room session and source, and resolve the publish promise rather than on socket write alone.

When reconnecting, send the last applied sequence cursors for each source. The server returns later events, including corrections, and the client applies them idempotently. Start and end offsets should be non-negative offsets from the room session's media epoch, with end_ms = start_ms. If capture restarts, issue a new session ID instead of resetting offsets.

The storage model includes an authoritative append log, an acceleration path for live channels, and compacted transcript objects for long-range reads and retention. Separate contracts for each view prevent optimizations from weakening other aspects. Acknowledge durability after append, use idempotent checks, and partition by room session to keep local ordering cheap and bound reconnect scans.