Scaling a stateless service is easy: add pods when CPU rises, remove them when it falls. A MongoDB replica set does not work like that. A secondary that is still catching up on replication is not really usable capacity yet. Count it anyway, and you think you have headroom you do not. Scale down after a failure, and you can remove a replica before it is safe to do so. Our paper proposes CAAS, a consistency-aware autoscaler for stateful microservices. It counts only non-stale secondaries toward capacity, plans scale-up over the full initial-sync horizon, keeps apply-headroom so a lagging member can catch up, and blocks unsafe scale-down until failure recovery is actually complete. Evaluation is simulation-only, using a Python discrete-event simulator 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 fell from 11.41% to 0.36% and stale reads from 5.68% to 0.03%. Results were strongest on read-dominated workloads; on write-heavy workloads the trade-off is real. The secure design elements were designed in the paper, not measured in the simulation. I would welcome discussion from researchers running stateful workloads in production: how do you gate scale-down on replication lag today, and what signal do you trust for "this secondary is ready"?