Modern distance learning platforms represent important infrastructure in contemporary higher education, particularly during periods of intensive use such as examinations, assignment deadlines, and simultaneous access to learning materials. In such situations, Learning Management System (LMS) platforms may face sudden traffic spikes that can lead to increased latency, reduced availability, and service degradation. Traditional autoscaling mechanisms in Kubernetes commonly rely on CPU or memory utilization, which may react too late when overload first appears at the network or application layer. This paper proposes a simulation-based latency-aware autoscaling model for LMS platforms in Kubernetes-like cloud-native environments. The model uses network latency measured at the ingress layer as an early control signal for adaptive horizontal scaling. The proposed architecture conceptually integrates the NGINX Ingress Controller, Prometheus-based telemetry, a Custom Metrics Adapter, and the Horizontal Pod Autoscaler within a closed feedback loop based on the MAPE-K paradigm. The model was evaluated through a Python-based simulation that replicates bursty load conditions in an LMS environment, supporting up to 2000 concurrent users or requests per second. The simulation results indicate that the latency-aware approach can initiate scaling earlier than a traditional CPU-based approach under the defined workload assumptions. In the simulated environment, the latency-aware model reduced the time to the first scaling action from approximately 90 s in the CPU-based baseline to approximately 12–15 s under the same workload assumptions. This result should not be interpreted as a direct reduction in application response time, but as an earlier activation of the scaling mechanism in the simulation. Since the validation was carried out in a simulated environment, rather than in a real Kubernetes cluster, these results should be interpreted within the limits of the simulation assumptions. In future research, the proposed model can be implemented in a real Kubernetes cluster using NGINX Ingress, Prometheus, HPA, and load generation tools such as Locust, JMeter, or k6.
Marković et al. (Thu,) studied this question.