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.…