Scaling a stateless service is easy: add pods when CPU rises, remove them when it falls.
A MongoDB replica set doesn't work like that. A secondary that's still catching up on replication isn't really usable capacity yet. Count it anyway, and you think you have headroom you don't. Scale down after a failure, and you can remove a replica before it's safe to do so.
That's the problem our paper tackles: consistency-aware autoscaling for stateful microservices under replication lag and failure-recovery constraints.
The core idea: count only fresh capacity
CAAS, the autoscaler in the paper, runs a MAPE-K loop with four rules that matter more than the loop itself:
- Lag detection that counts only non-stale secondaries. If a secondary is behind, it doesn't count toward available capacity, no matter what CPU says.
- Sync planning over the full initial-sync horizon. When scaling up, plan for the whole time a new member takes to sync — one sync at a time, from the least-busy member — instead of assuming a new replica is instantly ready.
- Apply-headroom for oplog resync. Keep headroom so a lagging member can actually catch up, rather than falling further behind under load.
- A recovery guard on scale-down. After a failure, block unsafe scale-down until recovery is actually complete.
In other words: don't treat a replica set like a pool of identical, instantly-ready workers. Treat replication state as part of capacity.
What we measured — in simulation
This is important to state plainly: the evaluation is simulation-only, using a Python discrete-event simulator called CASim, with 3 YCSB-inspired workloads, injected failures, 10 seeds, and 390 runs, compared against HPA, a predictive autoscaler, and HPA-MS.
On those simulated workloads:
- SLO violations: 11.41% → 0.36%
- Stale reads: 5.68% → 0.03%
Those are simulator results, and they're strongest on read-dominated workloads. On write-heavy workloads, the trade-off is real: CAAS used more members in some cases for worse read latency, even while write latency improved a lot. And the "secure" parts of the design — things like majority-committed reads and TLS/auth controls — were designed in the paper, not measured in the simulation, so I won't claim them as evaluated results here.
Why I'm sharing it here
If you run MongoDB or other stateful workloads on Kubernetes, you've probably hit some version of this: HPA says scale, the replica set says "not yet," and the safe answer isn't obvious in the moment.
I'd like to hear how you handle it in production:
- Do you gate scale-down on replication lag today, and if so, how?
- What signal do you actually trust for "this secondary is ready"?
- Have you seen initial-sync time blow up a scale-up plan in practice?
Paper
Consistency-Aware and Secure Autoscaling of Stateful Microservices under Replication Lag and Failure-Recovery Constraints
Swathi Gangarapu and Prashanth Mamidala
International Journal of Artificial Intelligence and Machine Learning, 6(13s), 1463–1475, 2026
DOI: 10.51483/IJAIML.2858
https://www.svedbergopen.com/index.php/ijaiml/article/view/2858
Top comments (0)