Applying it screen by screen
The questions are those of the playbook Decide on consistency; "Isolation Q3" is from Choose an isolation level.
| Screen / operation | Invariant or need | Question that decides | Choice |
|---|---|---|---|
| Bonus +100, transfer debit | No lost update on a balance | Q1 (commutes) | SET balance = balance - x in one statement |
| Main + savings withdrawal | balance(main) + balance(savings) >= 0, a rule over two rows | Isolation Q3 (a rule over several rows: write skew) | SERIALIZABLE, or lock a shared "household" row |
| Username creation | Uniqueness across regions | Q3 (fails the merge test) | Linearizable compare-and-swap in home region |
| First 1,000 promo | Upper bound | Q4 (split the budget) | Token quotas per region, refill on demand |
| Balance screen (Singapore) | Recent, not necessarily exact | Q3 → no coordination (state a bound) | Local replica with a 2 s staleness bound, alarmed on |
| Own-profile edit | See my own write | Q3 → no coordination (session token) | Token carried by the mobile client |
| Notes feed | Reply never before message | Q3 → no coordination (causal+ order) | Causal+ order; LWW is acceptable only for display name |
| Reward points | Counter that merges; never negative | Q1 and Q4 | PN-counter; bounded counter for redemption |
| Transfer confirmation shown across regions | Faster channel than replication (a phone call) | Q5 (external consistency) | Read that waits for the writer's token; external consistency for the confirmation flow |
| Merchant list behind a cache | The cache is a new observer | Q3 → no coordination (state the bound) | State the TTL as the staleness bound; do not cache balances |
The single most useful thing to carry forward is a question: