Engineering Case Study of New Oriental Cloud Classroom Backend Architecture and Scaling During the Pandemic

New Oriental Cloud Classroom (referred to as Cloud Classroom) currently serves over 100 branches and institutions with live courses, supporting millions of concurrent users across various class types such as small classes, multi‑video classes, dual‑teacher mother‑class, large classes, and H5 ultra‑large classes, with front‑ends on Windows, macOS, iOS, Android, and H5.

The core business system architecture includes modules for user management, registration/login, classroom scheduling, courseware, and institution management, and is divided into Client API (providing business interfaces to front‑ends), Open API (enabling external institutions to integrate core functionalities), and an admin backend for institutions lacking integration capabilities.

Cloud Classroom now reaches a daily active user base of over one million, handles around 100,000 daily courses, and supports massive classes with tens of thousands of participants simultaneously; the service level agreement demands availability above 99.9% and response times under 100 ms.

The server side is implemented in Java using Spring, Spring Boot, and MyBatis, with core data stored in MySQL employing master‑slave read/write separation, HA design, and sharding of large tables. A Redis cluster provides a dynamically scalable cache layer. Kafka is used for asynchronous processing, traffic shaping, and decoupling, while Sentinel adds flow monitoring, rate limiting, circuit breaking, and degradation protection. Distributed task scheduling is handled by XXL‑JOB, and Nacos serves as the configuration center. This architecture has been gradually built and refined over more than a year, especially accelerated by the pandemic.

The pandemic acted as a black‑swan event, causing a hundred‑fold increase in online education demand; the team responded by rapidly expanding infrastructure, optimizing performance and availability, enhancing monitoring, and handling numerous online incidents within a two‑week sprint.

To address the rapid growth of core large tables (millions of rows added daily), the team chose to archive historical data and introduce full‑table caching rather than sharding. The solution was designed, developed, tested, and deployed within one week, resulting in a ten‑fold improvement in core interface performance and a comparable reduction in system load.

Through these efforts, the team demonstrated strong battle‑readiness, matured its capabilities, and positioned itself to continue supporting the expanding business and contributing to the broader education industry.