Exercise 3: Why CP/AP Should Be Chosen Per-Operation, Not System-Wide — Possible Solution ==================================================================== THE STOCK-TRACKING SCENARIO: AP'S COST WAS REAL, BUT SURVIVABLE ------------------------------ This chapter verified AP's own real cost for stock tracking: two conflicting writes (45 and 42) both succeeded during a partition, and reconciliation afterward produced a value 5 units off from the true combined total (37). That's a genuine business cost - selling more units than actually exist, or under-reporting available stock - but it's a RECOVERABLE one: a human can review the discrepancy afterward, adjust the inventory count, and the business keeps running the whole time. Choosing AP for stock tracking trades a bounded, auditable error for keeping the store open during a partition - this chapter's own findings support that being a reasonable choice for this specific kind of data. THE LOGIN/AUTHENTICATION SCENARIO: CP-STYLE BEHAVIOR IS THE RIGHT DEFAULT ------------------------------ Now apply this chapter's own AP mechanism to authentication instead: during a partition, node_a and node_b could each independently accept or reject login attempts based on whichever copy of user credentials or session state they currently hold. Unlike stock levels, an authentication conflict isn't just numerically "a bit off" - it's a genuine security question: did this specific login attempt succeed or not, and does this specific user actually have valid access right now? Using this chapter's own reconciliation reasoning, there is no sensible "last-write-wins" or "highest-value-wins" analog for "was this person authenticated" - the two possible answers (allowed in, denied) aren't points on a scale that can be numerically or temporally reconciled after the fact. A CP-style choice - reject the login attempt rather than risk a wrong answer - is the safer default here, exactly because this chapter's own AP scenario showed reconciliation can silently lose information, which is tolerable for inventory counts and genuinely dangerous for access control. WHY THIS SUPPORTS DECIDING PER-OPERATION, NOT SYSTEM-WIDE ------------------------------ This chapter's own no-partition finding already showed CP and AP are indistinguishable until a partition happens - meaning the choice only ever matters for how a SPECIFIC operation behaves during that specific failure. A single system-wide CAP setting forces the SAME tradeoff onto every kind of data it stores, even though this chapter's own two scenarios show that tradeoff has genuinely different real-world stakes depending on what's being written. A real system would reasonably use AP-style logic for its stock-tracking writes (accepting this chapter's own verified, bounded reconciliation cost) while using CP-style logic for its authentication writes (accepting availability loss rather than risk a wrong access decision) - the same system, two different choices, made deliberately per kind of data rather than once for everything. WHY THIS WORKS AS AN ANSWER ------------------------------ The answer applies this chapter's own verified mechanism and reconciliation findings to a genuinely different kind of data (authentication instead of stock), identifies precisely why numeric reconciliation strategies don't transfer to a binary allow/deny decision, and uses that contrast to justify per-operation CAP choices rather than asserting it as a general best practice.