ORIGINAL COMPANY-CONTEXT PRACTICE
Fail over a balance display responsibly
Original practice scenario inspired by Citigroup Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A synthetic banking dashboard reads balances from regional replicas. Its primary region becomes unavailable while some replicas lag. Design the read behavior without presenting stale balances as current authorization to transfer funds.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Separate an informational balance display from the authoritative decision to move money. Replica failover can improve display availability while requiring clear freshness and stricter handling of transactional actions.
Work through it
- Attach an as-of watermark or version to displayed balances. Define a maximum permitted lag and show unavailable or stale status when that bound cannot be established.
- Route transfer authorization through a consistent authoritative path with concurrency control. Do not infer spendable funds solely from a cached display.
- Exercise failover with delayed replication, recovery, and repeated client requests. Measure freshness violations alongside availability and latency.
Tradeoffs to discuss
- Stronger read consistency can reduce availability during partitions. The appropriate choice can differ between a history screen and a transaction authorization path.
Common pitfalls
- A healthy replica endpoint may contain old data.
- Replacing unavailable with zero is misleading and can trigger incorrect user decisions.