Storage
Four concerns that look like one, and what falls out once they are separated.
Overview
Object storage looks like a single concern until it breaks. This document separates it into four, covers the ordering rules that make failures recoverable, why access boundaries must be verified against the provider rather than assumed, and the operations that only become possible once the separation exists.
Why This Exists
The first version of almost every storage layer treats the filesystem as the database: bytes go somewhere, the path is stored on the owning record, and orphan cleanup means scanning a directory. It works, and it keeps working until any one of five things is needed, at which point all of them are needed at once. The useful move is not adding features to that design. It is noticing that four separate concerns were fused, and that once they are separated, provider migration, health checks, signed access, deduplication and background repair stop being features to build and become consequences of the shape.
Four concerns, separated
One provider contract, and capabilities rather than names
Keys are policy, never caller input
A prefix is not a boundary
Ordering, because two systems are involved
Bytes and their metadata are separate stores that can disagree
Upload policy is a declaration both runtimes read
Related Principles· 3
Related Documents· 4
Referenced By· 1
Version History
- v0.1.0
Established. Separates the four fused concerns, states the provider contract and capability rule, makes keys policy-owned, records why a prefix is not an access boundary, gives the crash-safe orderings, and covers the two-store desynchronisation and shared upload policy.