Section 2: Promises You Can Measure - Requirements (Functional & Non-Functional)

Executive Summary: Section 1 ended with assumptions; this section converts them into promises a test could fail. Functionally the system is a short list of verbs over buckets and keys: put, get, head, delete, list with prefix and delimiter, multipart upload, range reads, conditional requests, presigned URLs and bucket policies, with objects up to 5 TB. Non-functionally it promises eleven nines of durability (a paper ceiling of about 100 lost objects a year across 10 trillion), 99.99% monthly availability (about 4.3 minutes of error budget), small-object GET at p99 100 ms and PUT at 200 ms, 700 GB/s of peak egress against 100 GB/s of ingest, strong consistency, tenant isolation and envelope encryption, all at hard-disk economics. Five features are deferred with reasons, and data-plane promises are separated from the softer control-plane ones.

The interviewer caps the marker. "You wrote down your assumptions. Now tell me what you're promising, with numbers, so I can tell when you've broken one."

You: "Three lists: what the system does, which I can demo; what it guarantees, which I can measure; and what I'm not building today, which I can defend. Then the data plane's promises apart from the control plane's, because pretending they are the same strength costs real money."

Functional requirements: the demo list

Each verb appears in Priya's integration at Lumen:

• Buckets: create, delete when empty, attach a policy. A namespace and a policy boundary, not a directory.
• PUT, GET, HEAD, DELETE object by (bucket, key). Priya's 40 KB thumbnail clip-00123/0001.jpg goes in with one PUT and comes back with one GET, later at high rate from a CDN origin pull.
• LIST with prefix, delimiter and pagination, at most 1,000 keys per page (N10). Lumen's nightly transcoder lists 2026/10/31/cam-07/ and expects key order.
• Multipart upload: initiate, upload parts in parallel, complete or abort. The 480 MB master clip-00123.mp4 arrives as 10 parts of 48 MB; parts are 5 MB to 5 GB, up to 10,000 of them, objects up to 5 TB (N10).
• Range GET: a player seeking into a master fetches one part's bytes without the rest.
• Conditional requests: ETags, If-Match, If-None-Match, for create-if-absent, cache validation and safe overwrites.
• Presigned URLs: Lumen's mobile app uploads straight to the store with a time-limited signature instead of routing 480 MB through Lumen's servers.
• Bucket policies on every request; user metadata up to 2 KB per object; keys up to 1,024 bytes of UTF-8 (N10).

The whole contract on one page.

Key Insight: Every functional requirement is a verb over a single key. No rename, no append, no directories, no transaction across keys. That absence lets the index be one ordered map and the data layer be immutable; Sections 5 and 9 spend that freedom. Adding "rename" signs you up for a distributed transaction across two keys.

Quick check before moving on: