splitting storage where the requirements actually differ

One storage design had grown to cover two subsystems that share a word and nothing else. Session messages are small, arrive continuously, need a total order, and are read far more recently than they are written. Attachments are large, arrive rarely, need no ordering at all, and their cost is dominated by capacity rather than latency.

Keeping them in one document meant averaging two sets of requirements that do not average: an ordering mechanism sized for bulk traffic, a durability policy tuned for conversation, thresholds right for neither. The design had already been through a dozen revisions trying to hold both.

The split was drawn where the requirements actually change. The message side keeps the ordered log: placement by content-derived hash across nodes, writes acknowledged by a set of holders rather than by a single owner, and a recorded open question about how ordering is established. The attachment side became a separate object store addressed by content hash, with erasure coding for bulk capacity, at a much earlier stage of design — a stub whose honesty about being a stub is part of the point.

One boundary had to be cut loose deliberately: an archived copy of a conversation must survive deletion of the live message, so the archival path cannot be a cascade from the delete path. That separation could only be argued once the two sides were things that could be discussed apart.

It proves the team will cut a design along a requirement seam even when the cut means rewriting the document that holds the product together.