Interactive Media Systems: Architecture Starts with Failure
Turning uploads, transcription and video search into a maintainable application: requirements, state models, module boundaries and tests for interactive media systems.
The upload is complete. The video plays. Search finds nothing because transcription failed in the background. To the backend, these are three different states. To the person at the screen, the application is broken.
This is exactly where software engineering for interactive media systems begins. It connects requirements, architecture and quality assurance so that individual components form an understandable overall workflow. Our example is a planned library for educational videos: upload, process, search for an explanation and play it directly at the relevant point.
Requirements must become observable
A functional requirement describes what the system should do. A quality requirement specifies under what conditions, and how well, it should do it. “The system provides video search” leaves important questions unanswered: does it search titles or spoken content? Does a result lead to the beginning of a video or a specific statement? What happens while the transcript is missing?
Requirements analysis, architecture, testing and operations therefore belong to a shared development process. The IEEE Computer Society’s SWEBOK Guide systematically organizes these areas. Washizaki, ed., 2024: Guide to the Software Engineering Body of Knowledge, Version 4
For our media library, a verifiable requirement would be: selecting a transcript result opens the correct video at the stored timestamp. This includes acceptance cases for missing media, invalid timestamps and revoked access rights. Only then can the team assess whether the feature is complete.
A timing target would also need a precise definition: what hardware, dataset and network conditions apply? An arbitrary millisecond figure without measurement conditions helps neither development nor eventual acceptance.
Model states before special cases spread
A single ready field would be too coarse for the example library. Playback and search may become available at different times. One possible design therefore separates media state from analysis state:
| Area | Example states | Meaning for the interface |
|---|---|---|
| Media file | Received, validated, playable, failed | Can the video already be used? |
| Transcript | Pending, in progress, available, failed | Can the spoken content be searched? |
| Search index | Pending, current, outdated | Which transcript version has been indexed? |
These states are a design proposal. What matters is defining permitted transitions. Retrying transcription, for example, must not reset playback that already works. A failed search index build must not make the existing transcript disappear.
The interface needs understandable messages derived from these states: “Video available; transcript being created” says more than an endless loading indicator. Part 3 on human–computer interaction discusses how to evaluate this feedback.
Draw module boundaries around responsibilities
One possible architecture contains media management, processing, search and a user interface. Media management knows about files and permissions. Processing produces transcripts and previews. Search indexes these results. The interface brings the user workflow together.
This separation does not initially require independent network services. For a small team, clearly separated modules within one application may be sufficient. Moving processing out later can be justified if it requires different hardware or independent scaling, for example. Google’s SRE textbook also discusses the operational value of simple, understandable systems. Google: Site Reliability Engineering, “Simplicity”
In our example, the search component should not need to know which transcription model was used. It needs a stable contract: text, time range, media version and provenance. This interface makes components replaceable without hiding differences in model quality. Part 4 on the data model develops this contract further.
Tests follow the important failure patterns
A component test can reject invalid timestamps. An integration test can check whether a saved transcript reaches the search index. An end-to-end test follows an upload through to playback of a search result. The system also needs checks for failures and retries. Application reliability depends in part on deliberately investigating foreseeable failures. Google: Site Reliability Engineering, “Testing for Reliability”
These situations would be particularly relevant to the library: the browser loses its connection after a successful upload. A job is delivered twice. A video is deleted while its transcript is still being processed. A permission changes after the search index has been created.
Expected outcomes should be established before implementation. In the last case, an older search result must certainly not grant access to a video that has since been restricted. Part 2 on web engineering covers the technical handling of these distributed workflows.
A complete workflow as the first milestone
For the example project, the first delivery would be small: import one video, store its metadata and play it. A saved transcript comes next, followed by search. Each addition extends a workflow that is already usable.
This makes incorrect assumptions at component boundaries visible early. Whether a more intelligent search justifies its cost can later be tested against this working starting point. The project article at the end of the series translates this sequence into concrete acceptance criteria.