Retention-First Object Storage: Signed Download Links for Resized Images in SaaS

In a healthtech SaaS, the hard part of image storage is not producing a 200-pixel thumbnail. It is proving that the original behind that thumbnail still belongs to the tenant and the selected backup snapshot when a deletion job, a restore, and a browser request happen close together.

Short answer: keep originals private, make thumbnails reproducible, and make the database manifest the authority for retention, deletion, restore selection, and signed links. The storage service should hold bytes; it should not decide which tenant snapshot an operator meant to restore.

That gives the team a useful definition of “simple.” A simple design has few hidden state transitions. It can answer which bytes may be deleted, which derivative can be regenerated, and why a download was authorized. Lowest price and shortest upload code are secondary until those answers are testable.

How should a Node.js SaaS app plan an object storage rollout for private image thumbnails?

The restore operation is the most revealing design exercise. Let an operator select snapshot snap_2026_07_14 for tenant clinic_42, then request one image at a thumbnail width that was never generated for that snapshot. The application should have a deterministic answer: read the manifest, find the private original, generate the derivative if policy permits, and publish the result under a key bound to that tenant and snapshot. It must not find a similarly named object from the current dataset.

The manifest therefore needs more than an object key. It should identify the tenant, snapshot, source image, derivative variant, retention deadline, deletion state, and any legal hold. A database transaction can record the state transition; object storage can record the bytes. A bucket listing is not a recovery record, and a path convention is not an authorization decision. In practice, I would make the drill exercise the same manifest reader used by the production restore path, then deliberately run it while a thumbnail job is queued and a deletion intent is pending; that single scenario forces the team to state which version wins, which state is visible to the operator, and which operation is allowed to proceed.

The invariants are deliberately boring:

• A restore selects one complete, named snapshot manifest owned by one tenant.
• A browser request resolves an image and variant through an authorized record, never through an arbitrary key.
• A thumbnail key is deterministic for its source snapshot, image, dimensions, and format.
• Deletion evaluates the source retention deadline and holds before the object operation.
• “Not generated,” “pending deletion,” and “unexpectedly missing” remain different states.

That last distinction protects operations. A missing derivative can be repaired from an original. A missing original can change the result of a restore.

What failure checks belong between image resizing and signed download links?

I would write the decision record around boundaries rather than brand names. The application owns identity, authorization, manifests, and retention decisions. The object layer owns private byte storage, upload parts, reads, and deletes under the application's instructions. A signer issues a short-lived bearer link only after the application has selected a ready variant.

The table is also a rejection test. If a candidate makes the application scrape listings to reconstruct a snapshot, it is a poor fit for this workflow regardless of how pleasant its SDK feels. If the team cannot explain what happens to abandoned multipart uploads, the upload path is not finished; large uploads create state that needs ownership and cleanup. The AWS multipart overview describes that model and its incomplete-upload considerations.

“Cheapest” is not a reliable selection rule here. Retained originals, thumbnail churn, requests, egress, replication, and abandoned uploads all belong in the workload model. I’m not sure which item dominates for your tenants without their retention schedule and traffic shape, so a byte-rate comparison alone would be false precision.

Which governance record makes retention auditable?

Node.js is an implementation detail; the authorization sequence is the important part. A request should load the tenant-scoped image record, verify the selected snapshot, choose an allowed variant, check its deletion state, and only then ask a storage adapter to sign a read. The adapter should receive an internal object reference, not a path copied from the query string.

from dataclasses import dataclass @dataclass(frozen=True) class DownloadRequest: tenant_id: str snapshot_id: str image_id: str width: int def authorize_thumbnail(request, image, now): if image.tenant_id != request.tenant_id: raise PermissionError("tenant boundary") if image.snapshot_id != request.snapshot_id: raise PermissionError("snapshot boundary") if image.retention_until <= now or image.deletion_requested_at is not None: raise PermissionError("retention boundary") variant = image.ready_variant(width=request.width) if variant is None: return {"state": "not_generated"} return {"state": "authorized", "object_key": variant.object_key} 

The real signer call belongs behind that contract. Its implementation can differ by backend without changing the restore or retention model. A five-minute link, for example, limits exposure time; it does not revoke a copied bearer link during that interval. The application should log the tenant, snapshot, variant, and authorization decision without logging sensitive image bytes.

Thumbnail generation follows the same boundary. Validate upload size, MIME type, dimensions, and decoded pixel count before invoking an image library. Store the original privately, enqueue a job containing an internal source reference, and write the derivative only after the worker has checked that the source remains eligible. Retries must use the same derived key and an idempotency record, so a queue retry does not create a second logical thumbnail.

The browser side needs its own contract. If uploads are direct, specify allowed origins and preflight behavior instead of treating CORS as a browser decoration; MDN documents why the origin and preflight exchange matter. If uploads pass through the application, enforce the same tenant and size checks there. “Simple” should describe the number of policies the team can explain, not merely the number of lines in a controller.

Can an implementation API survive a storage provider change?

Deletion should be a state machine with an audit trail. A scheduled job can create deletion intent, claim eligible records, issue the object operation, and reconcile the result. It should never delete by a broad prefix merely because that is convenient: a prefix can span snapshots, variants, or tenants unless the manifest has already narrowed the set.

Here is the small part worth testing independently:

def deletion_decision(item, now): if item.legal_hold: return "held" if item.retention_until > now: return "retained" if item.deletion_requested_at is None: return "needs_intent" return "eligible" def publish_variant(source, variant, now): if deletion_decision(source, now) != "retained": return "blocked" if variant.status != "writing": return "already_handled" return "write_deterministic_key" 

The worker needs explicit handling for a duplicate claim, an expired source, a held record, an absent derivative, and an incomplete multipart upload. Those are different operational states, even if several ultimately produce no browser download. Metrics for stuck deletion intents, orphaned variants, restore-manifest completeness, and resize retries expose the system's real behavior better than an upload success counter.

A signed URL should never be generated as a recovery attempt for a missing object. Return a controlled “not ready” state, classify the missing record, and let a repair job decide whether regeneration is allowed. This keeps a data-integrity question out of the request path.

When is a public derivative the wrong object?

The rejected shortcut is a single public object namespace with filenames that encode tenant and image IDs. It is suitable for disposable, non-sensitive derivatives when anyone may read them and losing a particular historical version has no recovery consequence. It is not suitable for private originals, regulated tenant data, or restores that must select an exact snapshot.

A self-managed storage layer is also the wrong fit when the team cannot operate retention audits, key protection, retry queues, restore drills, and incident access. The catch is that a managed object service is not automatically correct either: verify its retention, versioning, deletion, upload, and signing semantics against the contract above. A storage service is not the right tool for this design if it forces the application to reconstruct historical state from listings; choose a system with a manifest-friendly read model instead. The right choice is the one whose failure boundary the team can test and explain.

The decision record should end with a restore drill, not a pricing screenshot. Create two tenant snapshots with the same image ID, generate different variants, request one expired link, retry one resize, and run deletion while a restore is selected. The drill passes only when logs identify the tenant, snapshot, variant, and retention decision for every object operation.

References

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS
• https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html