Time-based or size-based retention for replay data before a Pulsar rollback?

Goal and constraint

Consider a namespace on a Pulsar 3.x cluster where recent messages must stay replayable if a deployment is rolled back. Only persistent topics backed by BookKeeper ledgers qualify, and bookie SSD capacity is limited, so retention cannot grow without bound. Tiered storage offload is available but adds retrieval latency for offloaded ledgers.

Two retention policies, one replay horizon

Time-based retention holds a fixed window regardless of traffic, but a rollback after a quiet stretch can find that window already purged. Size-based retention bounds disk use directly, yet a traffic spike can evict messages before the intended replay horizon passes. Once offload is enabled, retention and offload thresholds interact, and offloader behavior during broker failover is operator-configured and varies across releases.

Open questions

• Which policy preserves a guaranteed replay horizon under bursty traffic without exceeding bookie disk budgets?
• Can offload thresholds keep recently produced ledgers local until the replay window closes?
• Which release-specific checks confirm offload behavior during broker failover before relying on it?