Chapter 68Lesson 6
Quiz - Object storage
A teammate wants to add R2 to a brand-new B2B SaaS because “every file should live in object storage, it keeps the database clean.” Three of the app’s payloads are below. Which one actually crosses the threshold that puts a bucket on the table?
A 2 KB JSON blob of saved user preferences, tied to one row.
Contract PDFs that members upload and their teams download repeatedly.
The handful of hero and icon images on the marketing pages.
The threshold is a binary payload that outlives the request and would be wrong to inline in Postgres. The uploaded contracts are exactly that — user-supplied files, served back over and over. Preferences are tiny structured data (
jsonb), and marketing images are static assets known at build time (ship them with the build, the CDN serves them). “Keeps the database clean” is the seductive non-reason the lesson warns against — separation for its own sake buys a second store, a second credential surface, and a sync problem for nothing.A read-heavy SaaS serves 50 TB of user files back to browsers every month. Why does an experienced engineer reach for R2 over S3 here?
The bill for this product is dominated by bytes leaving the store on every download, and egress is the one line item R2 doesn’t meter while S3 does.
R2 is open source while S3 is proprietary, so R2 avoids the per-GB licensing fees baked into S3.
R2’s S3-compatible API is faster on the wire, so each of the 50 TB of downloads finishes sooner.
The call is unit economics, not licensing or speed. Both providers store the same files behind the same S3-compatible API and charge roughly the same for storage; the difference is egress — bytes leaving to reach a browser — which dominates a read-heavy bill and which R2 prices at zero. R2 is a managed service, not open source; the portability win is the shared S3 API, not a license.
You’re scoping the R2 token your Next.js app will authenticate with in production. Which grant is the senior default?
One token per environment, scoped to that environment’s single bucket, with Object Read & Write.
One Admin Read & Write token shared across staging and production, so you only manage one secret.
One account-level Object Read & Write token, so the same code reaches whichever bucket the environment points at.
The app only ever reads and writes objects — it never creates or deletes buckets, so Admin grade buys nothing and lets a leaked key wipe the account. “All buckets” means a leaked staging key reaches production data. A shared token collapses both environments’ blast radii into one. The rule is least access per environment: one bucket, Object Read & Write, separate tokens — so production credentials never touch localhost.
Your presigned upload works on a colleague’s machine but fails for a new contractor with a CORS error in the browser — the PUT is cancelled before it’s even sent, and the signature is definitely valid. Where is the fix?
On the bucket’s CORS rule — it must list the origin, method, and
content-type header the browser’s preflight asks for.In the signing code — the presigned URL must include the requesting origin in its signed parameters.
In the token scope — the R2 token needs the contractor’s origin added to its allowed-origins list.
CORS is enforced by the browser, configured on the bucket, and has nothing to do with whether the signature is valid — a cancelled-before-send PUT means the bucket never told the browser it was allowed. The fix is always the bucket’s CORS rule, never the signing call or the token. (Tokens don’t carry origins at all.) And on R2, list
content-type explicitly — the * wildcard for headers doesn’t reliably admit it.You sign a presigned PUT with ContentLength set to the client’s claimed size, and a content-type allow-list check before signing. A malicious client streams a 2 GB body through the valid URL anyway. Which check is the one that actually stops the oversized file from being accepted?
A post-upload
HeadObjectCommand that reads the real stored size from R2 and refuses to write the metadata row if it exceeds the cap.The signed
ContentLength — R2 rejects any PUT whose body exceeds the value baked into the signature.The content-type allow-list — once the type is approved before signing, R2 caps the body at the type’s expected size.
R2 does not enforce a maximum body size from the signed
ContentLength (unlike S3’s POST-policy content-length-range), so the signed length is not a boundary. The client pre-check is UX and the server cap trusts a typed number; only the post-upload HEAD reads the actual stored size and rejects before the row is written. That HEAD turns the metadata row into the function’s assertion that it verified the object. The content-type allow-list defends type, not size.An export feature emails users a download link. A teammate sets the presigned GET’s expiry to 24 hours “so the link works all day.” What’s the senior objection?
A long-lived signed URL is a leak surface — it sits in the email provider’s logs, the inbox, and every forward, downloadable by anyone for a full day; mail a link to an app route that mints a fresh short-lived GET on click instead.
24 hours is below R2’s minimum GET expiry, so R2 will silently clamp it and the link will be dead within minutes.
The expiry should instead be stored in the
file_metadata.url column so the link can be reused without re-signing.Presigned GETs are minted fresh, short-lived, and never persisted. A 24-hour link extends the trust window across every place the email lands — logs, history, forwards — with no further check. The fix isn’t a longer or stored URL; it’s emailing a link to a route you control that signs a fresh 10-minute GET when the recipient clicks. There’s no
url column precisely because a stored signed URL ages into a lie.In the safe direct-to-R2 upload flow, why is the file_metadata row inserted after the byte transfer completes rather than before?
Writing the row last biases failures toward orphan bytes (cheap litter a sweep reclaims) instead of orphan rows (a correctness bug where the UI lists a file that 404s).
The row can’t be built until the upload returns the object key, which the server only learns once R2 confirms the PUT.
Inserting before the upload would hold a database transaction open across the slow byte transfer.
Both failure directions exist, but they don’t cost the same. Write the row first and a failed upload leaves an orphan row — the database asserts a file that doesn’t exist, the link 404s, and that’s a correctness bug. Write it last and a failed finalize leaves only orphan bytes — invisible to the app, cheaply mopped up by a sweep or lifecycle rule. The server already constructs the object key before signing, so the key isn’t the reason; the asymmetry of the two failures is.
You’re choosing the uniqueness constraint for the objectKey column on file_metadata, which uses soft delete. Which is correct?
A plain global
.unique() with no where — the key stays unique even after the row is soft-deleted.A partial unique
where soft_deleted_at is null — only live rows compete for uniqueness, matching the slug pattern from earlier work.The reflex from unique slugs is a partial unique scoped to live rows — but it’s wrong here. The object may still physically exist in the bucket during its soft-delete cooling-off window, so a partial unique would let a soft-deleted row’s key be reused while its bytes are still in R2, and now two rows resolve to one blob. The key is unique forever, because the row and the object outlive the soft-delete by different amounts.
A user in org A pastes a fileId that really belongs to org B and hits the download route, which calls getFile('A', thatId) through tenantDb('A'). What comes back?
null — the org B row was never in the candidate set, so the lookup finds nothing and the route returns an ordinary 404.The org B row, so the route must then compare
row.organizationId against 'A' before trusting it.tenantDb('A') welds organizationId = 'A' into the SQL where before the query runs, so a foreign row is never in the result set — the lookup resolves to null and the route 404s, indistinguishable from a file that never existed. The whole point is that there’s no post-load if for a developer to forget; the scope makes the cross-tenant leak impossible to write, rather than relying on a remembered check.The chapter drilled “the function is never a byte pipe,” yet the CSV export’s Trigger.dev worker streams the whole file through itself with a server-side PutObjectCommand. Why isn’t that a violation?
The rule protects the synchronous request path — a user waiting, a timeout, a doubled per-request bandwidth bill. A background worker has none of those, and the bytes are already in memory, so presigning a PUT back to itself would be pure ceremony.
Server-side PUTs from a worker are exempt because the worker authenticates with the R2 token directly rather than a presigned URL.
The export is small enough to stay under the function timeout, so routing its bytes through the worker is acceptable where a large upload wouldn’t be.
Read the rule with its subject restored: a user-facing request handler is never a byte pipe, because of the timeout, the waiting user, and the doubled bandwidth. A background Trigger.dev run has no request to protect and already holds the assembled CSV, so a direct
PutObjectCommand is the simplest correct shape. It’s not about which credential is used or the file’s size — it’s about whether there’s a synchronous request in the path at all.User uploads get a file_metadata row; the CSV export output deliberately doesn’t. Which property of the export is the reason it skips the row?
It’s short-lived and single-consumer — one recipient clicking one emailed link inside a 10-minute window, never listed, owned, or managed, so a row would be write-only noise a lifecycle rule replaces.
It’s generated server-side rather than uploaded by a browser, and only browser PUTs are recorded in
file_metadata.It’s a CSV rather than a binary file, and
file_metadata only tracks binary payloads.A metadata row buys queryability, ownership, lifecycle, and audit — a user-managed file needs all four. The export needs none: one consumer, a few-minute lifetime, never listed or deleted from a settings screen. A prefix-scoped lifecycle rule reclaims the bytes. The decision rule is about lifetime and consumers, not the file’s format or who initiated the PUT — a server-generated long-lived multi-consumer asset would still earn a row.
Quiz complete
Score by topic