Section 12: Every Cent, Under Fire - Trade-offs, Alternatives & Interview Wrap-Up

Executive Summary: This closing section stress-tests the finished design. We run the five escalations interviewers reach for (buyer wallets, multi-currency, a second PSP, instant payouts, active-active), answering each by right-sizing first and then naming the options and the trigger that would move us. Then we condense the decisions into one table, compress the design into a 2-minute narration, present the 100-point scorecard, and name the real systems this question is asking about.

Fifty minutes in, the interviewer stops asking how things work and starts moving the requirements. A Senior answer bolts on a new box. A Staff answer names which existing decision the requirement touches, whether it flips, and what that costs.

The Escalation Gauntlet

Interviewer: "Add buyer wallets. Refunds go to store credit, and buyers spend it at checkout."

You: "That's the first requirement that breaks D5. Today every journal transaction touches one shard because accounts are keyed by seller_id. Suppose Maya's $40 tea refund became store credit, spent with Lantern & Loom. The wallet lives on Maya's shard; the seller's accounts live on shard k. Rather than 2PC, I'd run a saga through clearing accounts: transaction one, on the wallet's shard, debits buyer_wallet:maya and credits wallet_clearing@b; transaction two, on shard k, debits wallet_clearing@k and credits the seller and commission accounts. Each step has a deterministic idempotency key, a failed step is undone by a reversing entry, and the clearing accounts must net to zero across shards, which Section 11's nearline checks watch. If wallets become a large share of volume, that's D4's flip trigger: distributed SQL."

Interviewer: "We're launching in Europe and Japan."

You: "D6 already gives us the shape: int64 minor units plus a currency code, one currency per account. Lantern & Loom gets seller_available:lantern:EUR beside its USD account, with a per-currency exponent (yen has no minor unit). A conversion is its own journal transaction through FX accounts, at a rate locked when the buyer sees the price. Every transaction balances within each currency, and reconciliation runs per currency."

Interviewer: "Our PSP had a four-hour outage. Add a second one."

You: "Routing goes in the PSP Adapter, but only for new authorizations. An authorization lives at the PSP that issued it, so Maya's captures and refunds go back there. The ledger gets per-PSP receivables and reconciliation runs per PSP. The real cost is card data: hosted-field tokens belong to one PSP, so this is D15's flip trigger, network tokens or a third-party vault, and possibly a larger PCI scope, depending on how that vault's fields integrate."

Interviewer: "Sellers want their money instantly."

You: "Instant payouts are a speed-up of the transfer, not of the hold. They draw from available only, never pending, because the $3.7B pending float is what pays for refunds and chargebacks. They carry a fee, are risk-gated on tenure and dispute rate, and follow D11's ledger-first path. Lantern & Loom's $70.40 still becomes available on day 7. It just doesn't wait for the batch window."

Interviewer: "Make it active-active across regions."

You: "I'd decline. If two regions accept writes for one seller, both can see $70.40 available and both can pay it out: the double payout this system exists to prevent. Synchronous cross-region commit adds about 60 ms per commit against a 50 ms ledger p99. So D13 keeps one writer per shard, RPO 0 for an AZ, RPO ≤ 5 s for a region recovered by replay, and payouts frozen until reconciled. If a regulator demands RPO 0 on region loss, we move to distributed SQL across three regions and pay the latency on purpose."

Key Insight: None of the five escalations needed a new architecture. Each landed on a decision with a named flip trigger: wallets on D4/D5, cards on D15, regions on D13. When the requirement arrives, you're executing a plan instead of improvising.

Quick check before moving on: