Replay Large Bodies Without Pretending Memory Is Unlimited

Scope: Engineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.

A replay engine can preserve exact response bodies without loading an entire capture into memory at once. The important design question is how those bytes are authenticated and delivered under explicit resource limits.

Kalu’s current replay path uses verified body handles and on-demand reads. Backpressure and bounded readers help keep delivery connected to the resource profile rather than assuming every captured body can be eagerly retained.

Separate identity from residency

A body does not need to remain fully resident in memory for the engine to know which artifact it should serve. The source can retain a verified identity and open the corresponding bytes through a controlled read path when the request requires them.

In a synthetic capture with several large assets, this distinction avoids treating the total capture size as an automatic memory allocation. It also gives the engine a clearer place to enforce byte and concurrency bounds.

Streaming delivery does not weaken byte checks

On-demand delivery still needs to establish that the served bytes belong to the admitted artifact. A fast stream of the wrong file is not a correct replay. The verified-read boundary remains part of the path before backpressure-managed writes reach the response.

The capture hot path also contains bounded chunk handling. That is a mechanism for acquisition and delivery, not a benchmark claim that any size application will complete within a particular resource budget.

Do not infer protocol coverage from the transport mechanism

An engine that streams body bytes does not thereby support every streaming application protocol. WebSockets, server-sent events, range semantics, and other behaviors have separate contracts and qualification requirements.

The source distinguishes ordinary single-artifact HTTP bodies from its segment-based streaming engine. Those mechanisms should be explained separately rather than merged into a broad “all realtime supported” statement.

This article describes source-level resource handling, not universal performance or product availability. Actual limits and supported journeys remain part of the result.

For engineers, the useful question is whether the replay can account for what it retains, what it reads, and what happens when a bound is reached. Exactness and resource discipline are not competing goals. A bounded delivery path makes both easier to inspect.