Media assets · Upload & delivery
An upload is only the start of a media workflow.
Connecting large-file uploads with media records, topic metadata, sharing and downstream learning experiences.
- My contribution
- Backend & media-platform engineering
- Context
- Media asset infrastructure
- My responsibility
- Worked on media ingestion, metadata and integrations across the learning platform.
- The key decision
- Separate object transfer from media records, sharing relationships and downstream processing.
- What changed
- A media workflow that connects uploaded objects with topics, users, classes and learning-product integrations.
The problem & my responsibilities
Saving a file does not make it usable in a learning product. Large uploads need tracked completion, media needs searchable context, and a submission may belong to a user, class or school. Other services then need the same asset for galleries, showcases or video processing.
My work spans presigned upload workflows, media records, topic associations and sharing relationships. I connected those records with downstream services so uploaded media can participate in product workflows beyond the storage bucket.
Constraints that shaped the work
- Large files transferred in multiple parts
- Upload progress and stored media have different lifecycles
- Media shared across user, class and school contexts
- Processing and product integrations complete asynchronously
How the system fits together
- 01InitiateCreate the upload session and issue presigned part URLs
- 02CompleteReconcile uploaded parts and complete the storage object
- 03OrganiseAttach media records, topics and sharing relationships
- 04ConnectUpdate galleries and showcases or request downstream media processing
The consequential decisions
| Decision | Choice | Alternative | Trade-off |
|---|---|---|---|
| File transfer | Presigned multipart object uploads | Proxy the entire file through one application request | Clients can send parts to storage while the backend manages upload identity, metadata and completion. Part tracking and session expiry become explicit responsibilities. |
| Media identity | Separate the storage object from its product metadata | Treat the storage URL as the complete media record | Topics, user tags, class associations and sharing records let the same asset serve different product contexts without embedding those relationships in a filename. |
| Integration work | Queue handlers and service boundaries | Bundle upload, processing and every product update into one request | Upload-state updates and downstream actions have separate failure paths. Boundaries make it possible to track which part of the workflow still needs attention. |
Where the work got difficult
Know what has actually uploaded
Multipart completion needs the uploaded part numbers and ETags. The application tracks upload identity and status alongside the storage operation, rather than inferring completion from a client progress indicator.
Carry context across services
A media record may feed a showcase, a submission gallery or an HLS conversion request. Stable media references and explicit entity associations keep those integrations connected to the original asset.
Operating considerations
Access
Authenticated requests and sharing relationships need to agree on which user, class or school can retrieve an asset. Presigned transfer URLs also need appropriate expiry and scope.
Partial completion
Storage completion, metadata updates and downstream processing can fail independently. Upload status and error records are necessary for finding the stage that needs recovery.
Lifecycle
Upload sessions, temporary files and shared assets have different retention needs. Cleanup must account for media still referenced by learning activities.
Outcomes & lessons
The media platform connects multipart uploads to application media records, topic metadata and sharing relationships, with integrations into showcases, submissions and media processing. The design gives uploaded files a usable identity across the learning platform.
A useful media platform manages the asset’s place in the product as carefully as the bytes in storage.