An Indian UPI payments app ships about 45 production deploys a day across 120 services on Kubernetes. Last month a refactor of the PSP response parser passed all unit tests and a 10 percent canary that watched only HTTP 5xx, yet it mapped one sponsor bank's timeout response to FAILED instead of PENDING; 9,000 customers saw 'payment failed' after being debited. The festival season starts in five weeks.
The interviewer asks“Design the delivery pipeline for this platform. Changes that can move or misreport money need much stronger guarantees than a UI tweak, but we still want forty-plus deploys a day. How would you build it?”
I'd classify every change by the code paths it touches, so money-path changes (PSP adapters, state machine, ledger, recon, crypto) automatically get heavier gates while everything else stays fast. Those gates are specific: two approvals including a payments-core owner, contract tests against bank and NPCI simulators for every response code and timeout, ledger invariant tests, and a shadow or replay comparison of real traffic with side effects stubbed. In production, a progressive canary is judged on business metrics against the baseline — success rate per PSP and per bank, pending rate, timeout-to-failed mapping — not just 5xx, with automatic rollback and expand-and-contract data changes so rollback is real. Around festivals we freeze money paths with a documented break-glass process.
A free account unlocks the rest of it, and saves your progress across every track.
bash: variables Shell variables: assign, quote, default and exportbash: if Conditions: if, elif, else, test brackets and casebash: loops Loops: for, while read, until and retrybash: functions Functions: name a block, pass arguments, return a statusbash: arrays Arrays: lists and key-value maps in bashbash: exit codes Exit codes, $?, set -euo pipefail and trapbash: redirection Redirection: stdout, stderr, 2>&1, /dev/null and here-docsbash: arguments Script arguments: $1, $#, "$@", shift and getopts