A multi-region 311 status store must keep serving during network splits, yet operators also want strong consistency everywhere. What does the CAP theorem imply for this design?
Select an answer to reveal the explanation.
Short Explanation
CAP is the classic "pick your pain" rule when networks split. You cannot crank consistency, availability, and partition tolerance all the way up at the same time. Multi-region 311 status forces a conscious tradeoff, not a free lunch.
Full Explanation
CAP reasoning for a multi-region 311 status store is a trade-off under partition, not a promise that enough replicas unlock consistency, availability, and partition tolerance equally at once. When the WAN splits, the system must favor consistency or availability while still dealing with the partition; it cannot maximize all three properties simultaneously in the CAP sense taught in Big Data curricula. Claiming all three can be maximized together with enough replicas misunderstands the theorem and leads to designs that surprise operators during real city WAN blips. Ignoring partition tolerance because municipal WANs supposedly never fail is operationally false—regional links drop, and civic status pages must plan for that failure mode. Restricting CAP to relational warehouses alone is incorrect; the same trade-offs apply to NoSQL status stores that replicate across sites. Exam caveat: modern systems soften edges with tunable consistency, but the exam still expects the classic impossibility framing under partition. Operational check: simulate a network split between two regions in a staging cluster, observe whether the 311 status API stalls for consistency or serves possibly divergent answers for availability, and document the chosen stance for public communications staff.