Millions of parking-meter heartbeats arrive each hour and overwhelm a single primary database writer. Which NoSQL-oriented strategy best addresses this write pressure?
Select an answer to reveal the explanation.
Short Explanation
When meters scream all at once, one lonely writer melts. Horizontal NoSQL scale spreads those writes across many nodes. More lanes for the traffic, not a taller single toll booth.
Full Explanation
Millions of parking-meter heartbeats per hour overwhelm a single primary writer, so the NoSQL-oriented remedy is to scale writes horizontally across a distributed cluster designed for high ingest—partition keys, replicas, and many nodes sharing the write load. Serializing every heartbeat through one vertical mega-server without sharding recreates the bottleneck and fails open under peak festivals or shift changes. Dropping most heartbeats to protect the writer sacrifices operational visibility and can hide outages. Converting meters to weekly paper reports abandons near-real-time civic operations. Exam caveat: horizontal write scale still requires careful partition-key design; a single hot key can reintroduce saturation even on a large cluster. Operational check: load-test heartbeat ingest with realistic key cardinality, watch per-partition metrics, and confirm write latency stays within SLO as node count increases. In production terms for horizontal write scale for meter heartbeats, assign an owning team, wire a dashboard that shows the pattern is healthy under peak civic load, and require a staging drill that rehearses failure and recovery before resident impact. Revisit the choice when traffic shape, retention, or integrity needs change, and keep a named rollback owner on the change record. Re-test both the happy path and the failure path for horizontal write scale for meter heartbeats after material dependency upgrades so regressions are caught before the next public release.