A durability standard fixes the copy count and acknowledgement rule on a cluster whose storage bill has doubled - which levers cut the total, and in what order?

## Find the streams that are the bill Before any lever is pulled, get per-stream stored bytes and per-stream ingest. Estates like this are almost always skewed: a handful of streams carry most of the footprint, usually because something large is being carried in each record, or because a generous retention window was inherited by a stream that never replays anything. Acting uniformly across every stream is the classic waste - it spends review time on the tail and leaves the head untouched. The frame for everything below is the multiplication itself: `stored bytes = ingest rate x retention window x copy count`. Every lever is an attack on one of those three factors, and the order below follows from two rules: **act on the multiplicand before the multipliers**, and **prefer levers that cost no capability**. ## The levers, in order 1. **Reduce the bytes in each record.** This acts on the leftmost factor, so it is divided out of the entire product, and it is the only lever that also reduces the catch-up traffic every copy carries. Typical wins are structural rather than clever: stop carrying a large document inside the record when a reference to where it lives would do, drop fields nobody consumes, and stop republishing whole entities where a change would do. Whatever byte you never write is a byte you do not store `copy count x window` times. 2. **Correct retention windows nobody chose.** A cluster-wide default quietly becomes the window for every stream created afterwards, including streams whose consumers are strictly online and would never replay an hour, let alone a week. Per-stream overrides that match the actual replay requirement are usually the largest single reduction available, and they cost nothing that anyone was using. 3. **Move closed history to cheaper object storage.** Where the platform supports it, the older part of a stream leaves the expensive volumes while remaining readable, so the replay reach is preserved and only the recent part carries the full multiplier. This changes where bytes live rather than how many exist, so it reduces the expensive line and not the total byte count. 4. **Retire streams nobody reads.** Dead streams multiply exactly as enthusiastically as live ones. Ownership is the hard part, not deletion. 5. **Keep the heavy posture only where it is earned.** A standard applied uniformly means the least valuable stream on the cluster carries the same copy count and window as the most valuable. Splitting the standard into a small number of tiers is not a weakening of it - it is what makes it survivable. ## Why that order | Lever | Which factor | What it costs you | |---|---|---| | Fewer bytes per record | the rate | producer work; nothing operationally | | Retention matched to real replay need | the window | replay reach you were not using | | Closed history to cheaper storage | where bytes sit | slower reads of old records | | Retiring dead streams | the whole product | nothing, once ownership is established | | Lowering the copy count | the copy count | durability - this is a posture change | One subtlety is worth stating because it is a common interview trap: **cutting record bytes and shortening the window by the same percentage remove the same number of stored bytes**. The reason the first is ranked ahead is not arithmetic. It is that reducing bytes also reduces the traffic each copy carries and takes away no capability at all, while shortening the window takes away replay reach that somebody may be relying on quietly. ## Savings that are not savings - **Changing what a write waits for.** The acknowledgement rule decides latency and the failure behaviour of writes. It does not change how many copies are stored, so it removes no bytes at all. - **Lowering the floor on caught-up copies required for a write.** Same error in a different place: that floor governs whether writes are accepted, not how many copies exist on disk. - **Compressing after the fact.** Whatever reduces bytes must do so before the record is written, or the multiplier has already been applied on the way in and the traffic already paid. - **Deleting a stream's records manually** instead of fixing the window that keeps recreating the problem next week. ## What is not on the table here Two things are deliberately out of this conversation. The first is the **rate** - how bytes stored and bytes moved are priced, and which boundary crossings are metered, belongs to whoever owns the platform's billing model; this exercise produces quantities. The second is the **posture** itself. If the arithmetic has been worked, the levers are exhausted and the total still does not fit, then the honest next step is to go back to whoever set the durability standard and say so. Lowering a copy count or a window because a bill is uncomfortable, without that conversation, is how a cluster ends up with a durability guarantee nobody has reviewed and everybody assumes.