Five identical workers for a civic inventory sync all append to the same local file on a shared mount and capacity stops growing linearly. What is the scalability fix?
Select an answer to reveal the explanation.
Short Explanation
Five clerks scribbling in one notebook at once collide—they do not become five times faster. Shared writable files are a scale ceiling. Move the state to a proper shared store or shard it; spawning more writers against the file is not the fix.
Full Explanation
Linear capacity growth dies when five identical civic inventory workers collide on one mutable local file on a shared mount. Append contention, locking, and filesystem serialization create a single choke point; more workers often make it worse. The scalability fix is to move that state into a store designed for concurrent writers (database, queue, object store with keys) or to shard writes so workers do not fight over one file.
Starting more workers that still append to the same file fails because it multiplies writers against the bottleneck. Serializing all five onto one process that owns the file fails by deliberately destroying parallelism. Disabling load balancing so only one worker runs fails by capping throughput at one instance to avoid a design flaw that should be removed.
Exam caveat: a shared mount does not equal a safe shared store—NFS-style append to one file is still a contention design, even if labeled shared.
Operational check: under parallel load, measure write error rates and throughput before and after moving to a proper store or sharded keys; capacity should rise with worker count.
Treat the shared mount as transport for durable artifacts only after a safe writer protocol exists, not as a multi-writer log. Prefer append-only shards per worker with a later merge, or a queue where each message is claimed once. Civic inventory sync then scales with worker count because coordination moves into software designed for concurrency instead of competing POSIX appends on one path.