A live classroom can remain connected while one of its essential paths has already failed. Media may still be audible while courseware cannot load, or the lesson page may be synchronized while the video route is unstable. We designed the platform around independent media, courseware, and interaction paths so one degraded component did not force every participant to restart the lesson.
This article focuses on the failover boundaries between Agora, ZEGO, and our courseware engine. It explains what a provider switch can recover, what it cannot recover, and which lesson state must stay under application control.
Media, courseware, and classroom events do not share the same recovery policy. A media session needs compatible participants, a document needs a supported representation, and a late callback must not overwrite the current lesson state.
The result is a practical availability boundary: keep the lesson identity and teaching context stable while replacing only the capability that failed. The interaction protocol and monitoring evidence are covered in the companion articles linked below.
A Classroom Has Several Independent Paths to Keep Working
In an earlier article, I described our global real-time messaging architecture. That layer synchronized teacher actions such as page changes, annotations, and praise across participants connected to different service nodes.
However, reliable messaging addressed only one part of the classroom.
A page-change message could arrive promptly while the destination device was still unable to load the presentation. Audio could work while annotations stopped updating. A teacher could remain on the correct slide while students lost the video stream.
These were different problems, with different recovery options.
Our media integrations and courseware implementations therefore represented separate capabilities. Switching the audio/video provider did not inherently require switching the courseware engine. Likewise, trouble displaying lesson material did not automatically mean the current media connection needed to be replaced.
Figure 1. The platform combined independent media and courseware alternatives. Classroom events followed a Redis-to-database lifecycle separate from audio/video recording.
This separation also helps explain what “available” means. A connected Socket does not prove that students can hear the teacher. A successful media-room join does not prove that the lesson file is visible. Each capability needs to be assessed through the result it delivers to the classroom.
The application remains responsible for bringing these capabilities together around the same lesson, participants, and teaching activity.
Why We Integrated Both Agora and ZEGO
We did not have an independently operated global private network. Building and maintaining that infrastructure was a different undertaking from developing the education platform.
Instead, we integrated third-party RTC services for audio and video. Agora and ZEGO gave us two provider options, and we implemented the ability to switch the media route used by the classroom.
The purpose was practical: the platform should have another supported path when the current one was unsuitable. The alternative needed to be part of the application, rather than an emergency integration attempted during an incident.
At the same time, two RTC providers are not one shared media network. Their SDKs, authentication, room identifiers, publishing operations, and connection callbacks have their own behavior.
The lesson’s business identity should therefore remain distinct from a provider-specific channel or room. A change in media connection must not be interpreted as a new paid lesson, a different student, or a reset of the teaching material.
Media switching also has an important coordination boundary. Without a deliberately implemented bridge or dual-publishing arrangement, a teacher on one provider and students on the other should not be assumed to hear and see one another.
For the classroom to recover, the required participants need a compatible media path. Joining the target service is only part of that process; publishing and receiving usable media matter as well.
This is why I distinguish switching capability from a claim of zero interruption. Establishing a new connection, restoring publication, and subscribing to remote streams may introduce a visible or audible gap. The size of that gap depends on the implementation, network, device, and failure being handled.
There is also a difference between a provider problem and a participant problem. A broken microphone or a disconnected home network is unlikely to be fixed by changing RTC vendors. Moving a whole class because one device is struggling can introduce unnecessary disruption.
The engineering value of a second provider lies in having another recovery option. It does not remove the need to identify which part of the classroom is actually failing.
We Built the Primary Courseware Experience Ourselves
Courseware was central to the teaching experience, so we prioritized an in-house implementation.
The platform supported H5 packages, PowerPoint presentations, PDF documents, and images. Teachers could move through the material and write or draw on it, while the IM layer synchronized those actions to students.
Building this layer ourselves gave us control over the relationship between teaching actions and the application. A teacher changing a page was a classroom operation, not just a local viewer interaction. An annotation belonged to particular lesson content and needed to appear in the corresponding place on another device.
The formats introduced different kinds of state.
For an image sequence or a PDF, page identity captures much of the navigation state. PowerPoint may add animation steps. An H5 package can contain its own navigation, exercises, and interactive behavior.
That difference matters when discussing recovery. “Restore page 12” can be meaningful for a PDF, but insufficient for an H5 activity halfway through an interaction.
The same applies to annotations. Coordinates are useful only in relation to the content they describe. Different scaling, margins, page dimensions, or content versions can cause a correctly delivered stroke to appear in the wrong place.
The IM layer carried classroom actions, but the rendering layer still needed to interpret them consistently. Fast delivery and correct rendering are complementary responsibilities.
We also integrated ZEGO courseware as a backup and provided a switching capability. That gave the classroom another courseware implementation rather than leaving the custom renderer as its only option.
The backup did not make format differences disappear. Vendor file-sharing and whiteboard capabilities need to be checked against the specific files and interactions a lesson uses. A product supporting PowerPoint or H5 does not establish that every animation or custom package behaves identically across engines. ZEGO file-sharing overview
For an engineering review, the useful questions are concrete: Can the alternative open this asset? Does it identify pages consistently? Which annotations can be restored? Which interactions require a simpler representation?
A static version of a presentation may preserve the teaching content while losing animation. That can still be a useful degraded experience, provided the limitation is understood. Arbitrary H5 application state is a more demanding compatibility problem and should not be described as universally portable.
Our decision to build the primary experience and retain a vendor alternative reflected two needs: control over the normal classroom interaction and another supported way to present the material.
Switching a Component Still Requires Recovering the Lesson
The two switching capabilities addressed different parts of classroom continuity.
Media recovery concerns whether participants can communicate again. Courseware recovery concerns whether they can resume working with the relevant material. These responsibilities should remain separate even when the same classroom interface exposes both.
Figure 2. Media and courseware have separate recovery responsibilities. The diagram describes those responsibilities, not a particular automatic trigger or a zero-downtime guarantee.
Consider a lesson in which the teacher has already moved to a particular page and marked several words. Changing the video provider should not require the teacher to reopen the material and repeat those actions.
Conversely, changing the courseware implementation should preserve the ongoing conversation where the media path remains healthy.
This is where application state becomes more important than the presence of a second SDK. The platform needs a consistent understanding of which lesson is active, who controls it, which material is selected, and what state the classroom should resume.
The recovery boundary must also account for late activity from the old component. A delayed connection callback or a late page update should not silently pull the classroom back toward the previous state.
These are protocol responsibilities around switching. They should be implemented and verified explicitly rather than assumed to follow from a successful SDK initialization.
There is a similar issue when more than one system can synchronize courseware. Applying a remotely received action must not automatically turn it into a new local action and send it back again. Otherwise, connecting two implementations can create repeated updates rather than resilience.
A useful way to assess the feature is to look at the teacher’s next action. Can the teacher speak, move to the next page, and continue the explanation? Can students follow without reconstructing the lesson themselves?
That is a more meaningful recovery result than simply recording that a provider-selection flag changed.
Redis Supported the Live Lesson; the Database Preserved Its History
During an active lesson, we stored classroom messages in Redis for fast reads and writes. After the course ended, we synchronized those messages to the database for replay.
This divided the workload into two phases. The live classroom needed responsive interaction and access to active-session data. The database archive supported later retrieval of the lesson’s interaction history.
The approach also created a durability boundary. Before archival completed, messages that existed only in Redis depended on Redis and its configured recovery behavior.
Calling the data a cache does not make it disposable. If losing it would remove part of a lesson’s replay, it is temporarily carrying historical information that the business cares about.
Redis persistence and replication can reduce exposure, but they are not interchangeable with a guarantee that every acknowledged event survives. Redis documents asynchronous replication and the possibility of losing acknowledged writes during failover, depending on the configuration. Redis replication documentation
That is a tradeoff of the post-class archival design, not a reason to rewrite the project history as if every event had been durably stored elsewhere during the lesson.
The archival boundary deserves its own operational attention. Important questions include whether an interrupted synchronization can resume, whether retrying introduces duplicates, and when Redis data becomes eligible for cleanup.
A scheduled course end or a teacher closing the browser should not, by itself, be treated as evidence that the archive is complete. The meaningful result is that the expected lesson history has reached persistent storage.
If stronger loss guarantees become necessary, incremental archival during the lesson is a possible evolution. It would change the durability boundary, however, and should be described as an architectural change rather than a property of the original “Redis first, database after class” implementation.
There is also a distinction between interaction replay and media replay.
Stored messages can reconstruct page changes, annotations, and other classroom actions. They do not contain the teacher’s voice or the students’ video. Reproducing the full lesson requires the corresponding media recording and a way to align it with the interaction history.
Content versions matter as well. Replaying old page events against a replaced presentation or modified H5 package may show different material. A replay needs to identify the content used during that lesson, not merely its current filename.
Provider switching adds another consideration for full-session recording: media may belong to different provider sessions or recording segments. The interaction archive alone cannot establish that those segments are complete or correctly aligned.
For that reason, I treat live continuity, event archival, and complete media replay as related but distinct outcomes.
Exercise Each Recovery Boundary
Test each fallback independently in a staging classroom. The identifiers below are illustrative; record the actual provider, asset, and lesson state when you run the drill.
| Injected failure | Expected classroom result | Evidence to keep |
|---|---|---|
| Primary RTC provider stops accepting media | Required participants establish the supported backup route without changing the business lesson identity. | Lesson ID, provider session IDs, reconnect gap |
| Courseware engine cannot open the current asset | Fallback engine opens the documented representation or returns a clear degraded state. | Asset version, file type, rendered page |
| Old provider callback arrives after switching | Late callback cannot replace the active provider or lesson epoch. | Provider event, lesson epoch, accepted state |
| Redis-to-database archival stops after class | Replay remains pending and resumes without duplicate interaction events. | Archive job ID, event range, retry count |
The pass condition is continuity of the lesson state, not simply a successful SDK initialization. A gap or degraded rendering should be visible in the classroom and in the operational record.
What This Architecture Taught Me About Availability
The implemented framework gave us alternatives at two important business boundaries: the audio/video provider and the courseware engine. The messaging layer connected classroom actions, while Redis and post-class database synchronization supported the event lifecycle.
The lesson was that a backup becomes useful only when it fits the surrounding classroom behavior.
For media, the outcome is usable communication between the right participants. For courseware, it is the ability to continue teaching with the correct material and supported state. For archival, it is recoverable lesson history rather than merely a completed live session.
These are the kinds of failure scenarios I would use to assess the design:
| Situation | Recovery question |
|---|---|
| One student has a poor connection | Can that participant recover without unnecessarily disrupting the class? |
| The selected RTC path becomes unusable | Can the necessary participants establish usable media through the alternative? |
| The primary courseware engine cannot display the material | What content and interaction state can the backup preserve? |
| An old component reports activity after switching | Can it incorrectly overwrite the current classroom state? |
| Database synchronization is interrupted after class | Can the archive be completed without omissions or duplicates? |
| A replay crosses a provider switch | Are the required events, assets, and media segments available? |
The infrastructure beneath this application—ECS, MySQL, Redis, logs, metrics, and alerts—needs its own availability design. Multiple application capabilities still share dependencies, and a second media provider will not rescue an unavailable authentication service.
I will discuss that infrastructure separately. At the classroom level, the principle that guided this project was straightforward: give the lesson another way to continue, and be precise about what survives the transition.
Agora and ZEGO provided alternative media paths. Our own courseware implementation and ZEGO courseware provided alternative ways to present the lesson. IM synchronized classroom actions, and the event archive preserved the interaction history.
Together, these capabilities formed a working platform. Their value came from supporting the teacher and students through a disruption—not simply from increasing the number of vendors in the architecture.