Latency Versus Residency at Helio Bank
Helio Bank is designing a fraud-scoring service for card payments. The non-functional requirements are p95 scoring latency of 120 ms at 3,000 transactions per second, data residency in the bank's home country, and 99.95% monthly availability. The preferred vendor's SaaS product meets latency only in a cloud region in a neighboring country; the home-country region has no GPU instances and a documented 40 ms cross-border round trip. An on-premises GPU cluster would meet latency and residency but needs 14 weeks and a capital request. A hybrid option caches model scores locally for 15 minutes; the fraud team says that would let 6% of transactions use stale scores. The architecture review board wants a decision record before the next funding gate. The regulator has previously fined firms for cross-border transaction data transfers.
1. Evaluate the three architecture options against the stated non-functional requirements and recommend a direction for the review board.
Read the worked answer
The evaluation should first classify the requirements. Data residency is a hard legal constraint, not a preference, because the regulator has already penalized cross-border transfers. Latency is also a hard service-level objective at 120 ms p95 and 3,000 transactions per second. Availability is hard but can be met by several designs. The 6% stale-score figure is a business risk, not a latency number, and needs its own threshold.
The SaaS option fails residency on its face, even if it meets latency. The cross-border round trip alone consumes 40 ms of the 120 ms budget, leaving little room for model inference and network variability, and the legal exposure is severe.
The on-premises GPU cluster meets residency and latency on paper, but 14 weeks and a capital request create schedule and funding risk. It should be validated with a benchmark at target throughput, not accepted from vendor specifications.
The hybrid option is the weakest unless the fraud team accepts the stale-score risk. A 15-minute cache with 6% stale decisions may be tolerable for low-value transactions but not for all traffic. A segmented design - local scoring for high-risk transactions and cached scoring for low-risk ones - could reduce the exposure, but it requires an explicit risk acceptance.
The recommended direction is on-premises GPU with a phased benchmark and a temporary lower-throughput fallback, while the hybrid is held as a contingency only for an approved transaction segment.
2. What should the architecture decision record contain, and how should the team verify the chosen option after implementation?
Read the worked answer
The decision record should make the trade-off inspectable rather than merely announce a choice. It should contain: the context and the three options; the hard constraints of residency, latency, and availability; the quantified evidence, including the 40 ms cross-border round trip and the 6% stale-score exposure; the decision and its rationale; the rejected options and why; the residual risks, including the 14-week lead time and capital approval; and the conditions that would trigger reconsideration, such as a home-country GPU region becoming available.
Verification should use fitness functions tied to the requirements. A load test at 3,000 transactions per second should measure p95 latency under sustained and burst conditions. A residency audit should show where transaction data is stored, processed, and replicated, including logs and backups. An availability test should exercise failover against the 99.95% target. If the hybrid contingency is used, a monitoring check should report the percentage of decisions made from cached scores against the approved threshold. These checks should run in the pipeline and before go-live, so the decision is not just a document but an enforceable constraint.