An interviewer gives you this - your single-region platform has signed its first Indian payments customer, and the regulator requires payment system data to be stored in India. The CFO wants the cheapest compliant answer by the end of the quarter. Where do you start, and what do you refuse to build?

What the interviewer is testing

Whether you read the obligation before drawing boxes. Residency is a requirement about where bytes rest, not a requirement for a second copy of your architecture, and the candidates who hear "regulator" and answer "active-active multi-region" have just added a year and a permanent second operational surface to a problem that may need one database and a deletion job.

The clarifying questions that change the answer

• Which data is in scope? The Reserve Bank of India's April 2018 circular on storage of payment system data requires the entire data relating to the payment systems operated by a provider to be stored only in India. That is payment data - not your marketing site, your logs of page views or your HR system. The scoping exercise is the project.
• Can processing stay where it is? Under the same circular, foreign processing is permitted, but the data must be deleted from the systems abroad and brought back to India within one business day or 24 hours of processing, whichever is earlier. That one sentence is the difference between a storage footprint and a rebuild.
• Who is the regulated entity? If your customer is the payment system operator and you are their vendor, your obligations arrive through their contract, and the cheapest answer may be a deployment shape they already accept.
• Do Indian users also need low latency? A different requirement with a different answer. Conflating the two is how residency projects turn into multi-region projects.

A strong answer's arc

1. Inventory and classify. Name the tables and fields that constitute payment system data, and the pipelines that copy them - analytics warehouses and log sinks are where residency projects actually fail, because nobody tracks the fourth copy.
2. Place a storage footprint in-country for exactly that set. One database, its backups, and the object storage holding related artefacts.
3. Keep the control plane single-region. Deployment, identity, CI and monitoring are not payment data, and duplicating them buys nothing a regulator asked for.
4. If processing stays abroad, build the proof. The deletion and return within 24 hours is an auditable claim: you need a job, a log of what was deleted, and a report someone can read.
5. Write down the residency boundary as a decision record with the circular cited, because the next feature will want to join this data with something outside the boundary and the answer must be findable.

Common weak answers

• "Stand up a second region and replicate." Replication moves data in both directions by default, which is the opposite of the requirement. It also pays for availability you were not asked to buy.
• "Encrypt it and keep it where it is." Encryption is not location. Key residency arguments exist in some regimes; this circular speaks about storage.
• "We will handle it during the audit." The enforcement record is public: card networks were restricted from onboarding new domestic customers until compliance was demonstrated, with one restriction lifted in June 2022. The cost of being wrong is a revenue stop, not a finding.

What a strong answer adds

Name what you would refuse: a second full region, active-active writes, and a global data model rewrite, none of which the obligation requires. Then name the thing that is genuinely expensive and irreversible - the data inventory and the pipeline boundary - and say that it should be done once, for all future markets, because the second residency requirement always arrives.