At AIHYR, an AI-driven interview platform, we focus on building reliable and scalable interview experiences where every candidate interaction can be accurately evaluated. In such systems, consistent audio and video recording is not just a feature, it is a critical requirement.
As our platform scaled to real-world usage, we began encountering reliability issues in how interview recordings were captured.
Real-time communication platforms like Azure Communication Services (ACS), which are commonly used in applications such as telemedicine, virtual consultations, and customer support systems, are designed to handle these challenges more effectively. Inspired by these use cases, we transitioned from a file upload–based approach to a real-time media architecture.
The Original Approach: REST-Based Media Uploads
In a production interview platform, we initially relied on REST-based APIs to upload video and audio recordings for each answer directly from the browser to backend services. This approach worked reliably when candidates participated from stable, high-bandwidth networks.
What Broke in Real-World Usage
Although the interview flow completed successfully for candidates, reviewers occasionally discovered missing recordings during evaluation. In most cases the interview session itself appeared normal from the candidate’s perspective, but one or more answer recordings were incomplete or missing video.
From backend logs we observed patterns such as:
• Upload requests terminating before the full payload was received
• Partial media files stored in object storage
• Client retry attempts that eventually timed out under unstable network conditions
These failures were difficult to detect during the interview itself because the upload occurred only after the answer recording finished. By the time the failure surfaced, the candidate had already completed the interview.
This made the issue particularly problematic for interview workflows where every answer recording is expected to be available for evaluation.
Why REST Uploads Struggle with Media Reliability
REST APIs work well for transactional data, but media uploads behave very differently from typical API requests.
In our original design, each interview answer was recorded in the browser and uploaded as a media file. This meant the entire reliability of the recording depended on the candidate’s network conditions at the moment of upload.
Several failure scenarios emerged:
• Large payload uploads – Video files are significantly larger than typical API requests, making them sensitive to packet loss and bandwidth fluctuations.
• Client-side dependency – If the browser tab closed, refreshed, or lost connectivity, uploads could terminate mid-transfer.
• Retry limitations – Retrying uploads increased complexity but did not solve the root problem when network stability was consistently poor.
• Delayed failure detection – Because uploads occurred after recording, failures were discovered only after the interview had already completed.
These characteristics made REST-based uploads fragile for real-world interview environments where network quality varied significantly between candidates.
Why Real-Time Media Calls Improved Reliability
In the new architecture, candidates join a group call session created through Azure Communication Services. Media flows continuously between participants using WebRTC, while the ACS recording service captures the session server-side and generates a recording file once the call ends.
Azure Communication Services uses WebRTC-based media transport, which is designed specifically for real-time communication. Rather than relying on a large files transfer, media is sent as a continuous stream of small packets that adapt dynamically to network conditions.
This approach provides several advantages:
• Adaptive bitrate – Video quality automatically adjusts when bandwidth changes.
• Packet-level recovery mechanisms optimized for media streams.
• Continuous transmission, reducing the risk of losing an entire recording due to a failed upload.
• Server-side recording, allowing the platform to capture the full interview session independently of the client’s upload success.
As a result, temporary network instability is far less likely to cause complete recording failures.
Observed Impact After Migration
After moving from REST-based uploads to ACS-based call recording, we observed several operational improvements:
• Recording failures caused by incomplete uploads became significantly less frequent.
• Interview sessions that previously produced partial recordings were largely eliminated.
• Recording reliability improved for candidates joining from unstable or mobile networks.
• Debugging recording issues became easier because the system captured media continuously during the session instead of relying on uploads during interview.
Although the system still encounters occasional edge cases- such as call join failures, the overall reliability of interview recordings improved substantially compared to the earlier upload-based approach.
Key Takeaway
Moving from REST-based media uploads to real-time streaming fundamentally changed how we approached reliability. Instead of reacting to failures after they occurred, we designed the system to adapt continuously to network conditions. While no solution is without trade-offs, this shift significantly reduced silent failures and improved confidence in the interview process.
Top comments (0)