A social media app must scale writes horizontally across several regions to absorb viral traffic spikes. A post's like count can be briefly out of date between regions without harming the business, and the post format changes often. Which choice best fits these requirements?

Many non-relational databases are designed to partition data across many nodes and replicate it between regions, so write capacity grows by adding servers rather than buying a bigger one. To stay available and fast under that distribution, they commonly follow the BASE model: basically available, soft state, eventually consistent. Replicas accept writes locally and converge over time, which is acceptable when, as here, a like count can lag briefly. A flexible schema also absorbs frequent changes to the post format without table migrations. Scaling a single relational node vertically has a hard ceiling and leaves a single point of failure, and it does not place data close to users in several regions. Enforcing strict ACID consistency across regions on every write requires coordination between distant sites before each commit, adding latency and reducing availability during spikes, which is the cost the business has said it does not need to pay for like counts. A nightly warehouse refresh serves analytics, not live application writes, and would leave counts a day stale. Exam caveat: data that does need strong consistency, such as account balances, may still belong in a relational system in the same application. Operational check: simulate a regional traffic spike in a test cluster, measure write throughput, and observe how long replicas take to converge on the same count.