The Transcription Challenge: Beyond the Model
Developing a web application that reliably turns public video URLs and local media into searchable transcripts and subtitle files presents a significant engineering challenge. While the AI transcription model itself might be the core function, the true difficulty lies in building a resilient pipeline capable of handling real-world complexities. This includes managing large uploads, retrying failed requests, dealing with duplicate callbacks, processing partially failed batches, and enabling seamless deployment rollbacks.
HiTranscript, a web app developed by Bill King, demonstrates a robust architecture pattern for achieving this reliability using Cloudflare Workers. The system leverages explicit job states, durable media handoffs, idempotent callbacks, item-level batch tracking, and a single normalized timeline for all output formats.
Architectural Overview
The HiTranscript application employs a modern tech stack to achieve its reliability goals. The web layer is built with TanStack Start and TypeScript, providing a dynamic and type-safe user interface. For persistent task state management, PostgreSQL is utilized, ensuring that job progress and details are durably stored. The core orchestration and media storage are handled by Cloudflare's serverless offerings: Workers for compute, Queues for asynchronous task processing, and R2 for object storage.

This combination allows for a scalable, cost-effective, and highly available system. Cloudflare Workers provide the edge compute necessary to process incoming requests and manage job states efficiently, while R2 offers a cost-efficient and durable solution for storing media files. PostgreSQL acts as the system's memory, keeping track of every step in the transcription process.
Explicit Job States for Predictability
A critical pattern for reliability is the implementation of explicit job states. Instead of relying on implicit states or simple boolean flags, each transcription job moves through a clearly defined sequence of states. This could include states like `PENDING`, `PROCESSING`, `FAILED_PARTIAL`, `COMPLETED`, or `ROLLING_BACK`. By having these distinct states, the system can reason about the current status of any given job with certainty. This makes it easier to implement retry logic, handle errors gracefully, and provide accurate progress updates to users. When a job fails, its state clearly indicates the problem, preventing ambiguous situations where the system might not know whether to retry or consider the job done.
Durable Media Handoffs
Managing media files, especially large ones, requires a durable handoff mechanism. In HiTranscript's architecture, Cloudflare R2 serves this purpose. When a user uploads a file or provides a video URL, the media is stored in R2. Instead of passing large files directly between services, the system passes references (like R2 object keys or pre-signed URLs) to these files. This ensures that the media is stored durably and is accessible throughout the transcription pipeline. If a processing step fails, the media remains safely in R2, and the job can be restarted without requiring the user to re-upload the file. This approach is akin to leaving a securely locked package at a trusted courier's depot rather than trying to hand-carry it through multiple checkpoints, where it could be lost or damaged.
Idempotent Callbacks for Robustness
External services and internal queues often communicate via callbacks. In a distributed system, these callbacks can be retried due to network issues or transient failures. To handle this, HiTranscript implements idempotent callbacks. An idempotent operation is one that can be applied multiple times without changing the result beyond the initial application. For callbacks, this means that if a callback is received twice, the system only processes the action once. For example, if a callback signals that a transcription segment is ready, the system will record this information. If the same callback arrives again, it will be recognized as a duplicate and ignored, preventing the same segment from being processed or recorded multiple times, which could lead to data corruption or incorrect output.
Item-Level Batch Tracking
Transcription jobs often involve processing large batches of data. A common failure mode is when a batch partially fails – some items succeed, while others fail. HiTranscript addresses this with item-level batch tracking. Instead of treating the entire batch as a single unit that either succeeds or fails, the system tracks the status of each individual item within the batch. This allows for granular error handling. If 99 out of 100 audio segments in a batch are transcribed successfully, the system can report the successful ones, flag the failed segment for retry, and still consider the overall job as partially completed. This precision is vital for providing meaningful feedback to users and for optimizing retry strategies.
A Single Normalized Timeline
Finally, generating multiple output formats (like searchable transcripts, SRT subtitles, VTT captions) from a single transcription process requires a unified view of the data. HiTranscript achieves this by maintaining a single normalized timeline. All transcription events and timings are stored in a consistent format. From this normalized representation, any required output format can be generated. This prevents inconsistencies that might arise from generating each format independently. It acts as a master record from which all other representations are derived, ensuring that the transcript, subtitles, and captions are all synchronized and accurate with respect to the original audio.
Conclusion: Reliability Through Architecture
The success of HiTranscript highlights that building reliable AI-powered applications, particularly those involving media processing and asynchronous workflows, hinges more on robust pipeline architecture than on the AI model alone. By implementing patterns like explicit job states, durable media handoffs, idempotent callbacks, item-level batch tracking, and a normalized timeline, developers can create systems that are resilient to common failures and complexities of distributed computing. Cloudflare's serverless offerings provide a powerful and cost-effective foundation for implementing these patterns at scale.
