Attachments: EPIC 3 — Performance Optimization - JU-DEV-Bootcamps/ERAS GitHub Wiki

Description: Enable direct client-to-storage uploads via pre-signed URLs, and accelerate downloads via a CDN layer. Fully new work — today all uploads/downloads pass through the backend as streams.

Acceptance Criteria:

  • Upload traffic no longer passes through the backend server's memory/CPU.
  • Frequently accessed attachments are served from edge cache rather than hitting object storage on every request.
  • Both optimizations preserve the security model from Epic 2 (private containers, signed access).

User Story 3.1 — Direct Client Uploads via Temporary URLs

Description: As a client application, I want to upload files directly to Swift using a PUT-scoped Temporary URL (TempURL) issued by the backend, so large uploads don't consume backend resources. Because Swift's at-rest encryption (US 2.1) applies transparently at the proxy level rather than per-request the way S3's SSE header does, no extra header needs to be enforced on the upload URL — encryption is guaranteed by the cluster configuration regardless of upload path, which simplifies this story compared to the original S3-based design.

Acceptance Criteria:

  • Backend exposes an "initiate upload" call returning a PUT-scoped Temporary URL plus a pending Attachment metadata record.
  • A confirmation step finalizes the metadata record only after successful upload, verified via a HEAD request on the object.
  • Backend never buffers the file payload itself in this flow.
  • The Temporary URL is scoped to a single object path and the PUT method, and expires per the configured TTL, so it can't be reused for other objects or reused indefinitely.

Tasks:

  • Task 3.1.1 — Implement PUT-scoped Temporary URL generation AC: URL permits upload only within its TTL, only via PUT, and only to the intended object path.
  • Task 3.1.2 — Implement upload confirmation and pending-state handling AC: Records never confirmed within a configurable window are identifiable for cleanup; confirmed records reflect actual object presence, verified via HEAD.

User Story 3.2 — CDN Integration for Downloads

Description: As an end user, I want frequently accessed attachments to load quickly regardless of location.

Acceptance Criteria:

  • A CDN is configured in front of the object storage provider for read paths.
  • Cache invalidation triggers on attachment update/delete.
  • Private/signed-URL content continues to respect access control through the CDN layer.

Tasks:

  • Task 3.2.1 — Configure CDN distribution in front of the storage container AC: Repeated downloads of the same object show reduced latency from edge locations.
  • Task 3.2.2 — Implement cache invalidation on delete/update AC: A deleted attachment is no longer servable from cache after invalidation completes.