Object storage: blobs, durability and cost

An object holds bytes plus metadata under a key in a bucket. Keep searchable application metadata in a database. Prefer a new key for each blob version. Uploading bytes and publishing a database pointer are separate operations: reconcile orphan uploads and dangling pointers.

A network outage can make intact objects unavailable. Permanent loss harms durability even if other requests succeed. Durability estimates, availability targets and request measurements have different denominators and time horizons; do not convert one into the other.

Replication stores complete copies. Three copies have 3x raw storage overhead. Placement matters: three copies on one rack do not survive a rack loss. Repair must restore redundancy before further failures exhaust it.

An ideal maximum-distance-separable code reconstructs from any k of k+m fragments. Raw overhead is (k+m)/k. It tolerates m fragment erasures per group, not arbitrary failures of m regions. Reconstruction and repair consume compute and bandwidth. Placement still determines which failures destroy too many fragments together.

Separate stored GB-month from transferred GB. Use provider-billed storage: do not multiply by internal redundancy again when included in the rate. Download frequency and cache misses drive egress. These prices are teaching inputs, not current market rates.

A cold archive may favor coding efficiency; a small hot object may favor simpler reads. Neither choice alone proves a durability target. Test degraded reads, repair load and failure-domain placement against the workload.

Try a fresh variant, then score at least 80% on the mastery check. Wrong answers link back to the teaching step.