# Exercise 2: Diagnose a Split-Brain Incident and Propose a Fix

## Scenario

`InvenTrack`, a warehouse inventory system, runs a 3-node cluster (Node 1, Node 2, Node 3) that was configured, without much thought at the time, to always accept both reads and writes on every node — the team wanted to guarantee the warehouse floor's handheld scanners could always record a stock movement, even if the network was flaky.

Last week, a switch failure partitioned the cluster into [Node 1] | [Node 2, Node 3] for about six minutes. During that window:

- A worker on the floor near Node 1 scanned out the last 3 units of SKU `WH-4471` (a bestselling item), which Node 1 recorded as `quantity = 0`.
- Simultaneously, a worker near Node 2 scanned in 50 new units of the SAME SKU `WH-4471` arriving from a supplier truck, which Node 2 recorded as `quantity = 53` (50 new + the 3 that, from Node 2's view, were never scanned out, since it never heard about Node 1's write).
- When the partition healed, the two values (`0` and `53`) had to be reconciled. The system's reconciliation logic picked "last write wins by timestamp," which happened to pick Node 2's `53` — silently discarding the scan-out that had actually already been fulfilled and shipped to a customer.
- Result: the warehouse's system now shows 53 units of `WH-4471` in stock, but physically there are only 50, because 3 were already shipped based on the (now-discarded) write. A week later, three separate customer orders for that SKU failed at fulfillment because the physical stock didn't match the system.

## Deliverables

Produce all of the following, in this file, below this line:

1. **Classify InvenTrack's actual (as-built) behavior as CP or AP**, and explain, using theory Section 4, exactly why "last write wins by timestamp" reconciliation was guaranteed to be able to silently lose a real, physically-already-happened write like the scan-out — not just that it "happened to" in this case.
2. **Propose a CP redesign for this specific SKU-quantity data**, describing concretely what the system should have done during the partition instead (theory Section 3) — what would the worker's handheld scanner have shown when it tried to scan out those last 3 units if Node 1 had refused the write?
3. **Argue why a full CP redesign for EVERY piece of InvenTrack's data would be the wrong call**, using theory Section 5's point that the choice is usually per-data-type, not universal — name at least one other piece of data this system plausibly tracks (you may invent something realistic, e.g. a warehouse map layout, a worker's shift clock-in) that should stay AP, and justify why.
4. **Propose a better reconciliation strategy than "last write wins by timestamp"** specifically for inventory quantities during an AP window (if the team had instead decided quantity SHOULD stay AP for availability reasons) — e.g., something that wouldn't have silently discarded a physically-real stock movement the way this incident did.