From Upload to Stream: Distributing a Media Platform

Clicking “Play” can trigger authentication, authorization, a metadata query and several file requests. Meanwhile, transcription may still be running. Web engineering for media platforms has to coordinate these workflows across browser, network and server.

Our example media library should remain understandable even when some of this work takes longer or fails. It helps to consider three workflows separately: managing the media object, processing it and delivering the actual content.

An interface describes more than JSON

REST is an architectural style with several constraints, including client–server separation, stateless interactions, cacheability and a uniform interface. Stateless does not mean the server cannot store data. A request should contain the information needed to process it without depending on an implicit sequence of session interactions. Simply using HTTP and JSON does not make an API fully REST-compliant. Fielding, 2000: Architectural Styles and the Design of Network-based Software Architectures, Chapter 5

In the library design, a video would receive its own identity. Its metadata could already be available while processing is still pending. A separate job describes transcription progress. This means the browser does not have to keep a single request open for minutes until a completed result eventually arrives.

The interface could poll the job or receive updates through a suitable event channel. Which option makes sense depends, among other things, on the required freshness and operational effort. For a first prototype, a simple status query would be easier to verify.

A retry must not create a second version of the truth

Suppose the server has saved an upload. The connection then breaks before the browser receives confirmation. From the client’s perspective, retrying makes sense. Without a countermeasure, two media objects are created.

One possible design therefore assigns a unique identifier to the logical upload operation. The server stores this identifier together with the result and recognizes retries. The same identifier with conflicting content would have to be rejected. How long identifiers are retained is also part of the contract.

Background processing requires similar reasoning. A redelivered job should not create uncontrolled duplicates of an existing transcript. A combination of media version and processing version can serve as a domain key. The database perspective in Part 4 adds the necessary uniqueness rules.

Why videos are delivered in segments

HTTP Live Streaming, HLS, describes media playlists and individual segments. Different variants can offer different bitrates, allowing a player to respond to changing network conditions. Segmentation, buffering and variant selection jointly affect startup delay and interruptions. RFC 8216 documents the basic structure of this approach. Pantos and May, 2017: RFC 8216, HTTP Live Streaming

For the example library, the decision would depend on its audience. A small internal collection can begin with simple file delivery. With varied devices and unstable connections, several prepared playback variants may be useful. The additional files incur storage and processing costs that must be weighed against their benefit.

A smaller video file alone also cannot solve a poor connection. The player must clearly display its state and resume sensibly after interruptions. This is where technical delivery meets the UX evaluation in Part 3.

Caching requires a domain decision

HTTP caches store suitable responses for reuse. Freshness information and validation control when a stored response may be reused. Public media and personalized responses have different requirements. RFC 9111 describes the relevant rules and headers. Fielding, Nottingham and Reschke, 2022: RFC 9111, HTTP Caching

In our library, immutable previews could receive version-specific addresses. A change creates a new address. A personal collection needs different rules because its response depends on the signed-in account. A shared cache must preserve this distinction.

A content delivery network can move delivery closer to users. It does not replace authorization or a deletion strategy. The project must make it possible to trace which copies exist and how restricted content becomes inaccessible.

Make delayed updates visible

A video may be stored before the search index is updated. In the example design, this delay would be acceptable if the interface explains it. For access rights, however, an outdated decision would not be a sufficient basis for delivery.

The library would therefore check permissions at the actual access points. An old index entry must not expose a confidential text preview to an unauthorized person either. This already affects search, not just the player.

For troubleshooting, upload, processing and indexing would receive related identifiers. This would make it possible to trace a media object’s path without writing entire transcripts into technical logs. Media processing in Part 7 supplies the files and timestamps that this platform ultimately transports.