Stop-writes failure condition in namespace storage engine for repeatable development

Goal is a repeatable local development environment for Aerospike Server where namespace configuration and storage engine behavior are predictable across restarts and resource constrained runs.

Constraints include small memory or disk limits to surface resource pressure, choice between in-memory and persistent storage per namespace, and single-node cluster defaults that affect client routing and partition maps. Stop-writes failure condition in the namespace storage engine engages when high-water thresholds are exceeded, rejecting writes until usage falls.

Behavior of high-water marks and stop-writes is version sensitive and depends on storage engine type and namespace settings. Community versus Enterprise feature sets differ for persistence and monitoring, affecting reproducibility assumptions.

What namespace storage engine parameters define stop-writes engagement for memory and disk high-water thresholds in a single-node dev setup? Does persistence mode change the reproducibility of stop-writes across restarts? Should replication factor one with a single node be pinned for repeatable tests, or does multi-node emulation change failure visibility?