Product manager interview: How would you design SaaS data-residency controls?

Prompt and context

A B2B SaaS service runs in several cloud regions. A customer wants “data to stay in Germany” while also requiring high availability, support troubleshooting, and cross-region disaster recovery. Define the data and processing covered by the promise, then design region selection, replication, backups, operator access, exit, and evidence so the promise is testable rather than marketing copy.

What the interviewer is testing

• Separating residency boundaries for customer content, backups, logs, telemetry, support tickets, and model processing.
• Connecting customer choice, write routing, replication guardrails, keys, and human access into one control loop.
• Explaining the real trade-offs between residency, sovereignty, availability, and disaster recovery.
• Defining auditable evidence, alerts, and customer communication instead of a region dropdown alone.

Questions to clarify first

1. Does the customer require storage, processing, operator-access, or legal-jurisdiction residency?
2. Which data is customer content versus account metadata, logs, backups, and support attachments?
3. May a single-region outage pause writes, or must the service recover cross-region?
4. What regional controls, service dependencies, and key-management capabilities does the cloud provider offer?
5. Does the customer need self-service evidence, an audit export, or a contract promise with an exception process?

A 30-second answer framework

I would split residency into storage, processing, replication, and human-access boundaries and inventory each data class. Once a customer selects a region, routing, databases, object storage, backups, logs, and keys must enforce the same policy; a region label alone is insufficient. Failure behavior—pause, degrade, or cross-region recovery—must be explicit, and every exception must create an alert and audit evidence. Validate the promise with real write, replication, and recovery exercises before launch.

Step-by-step deep answer

Step 1: Define what the promise covers

Inventory customer content, search indexes, derived files, backups, logs, telemetry, billing data, and support attachments. For each, record storage, processing, replication, retention, and operator-access locations. Define a region as a verifiable geography and dependency set, rather than turning a cloud-console region name into a legal guarantee.

Step 2: Design tenant region selection

Choose a residency package at tenant creation and store an immutable policy version. A policy service should provide one decision to every write path so an asynchronous job cannot bypass routing. Migration needs approval, a dual-write window, and completion evidence; changing a dropdown cannot prove that historical copies moved.

Step 3: Build replication and backup guardrails

Database replication, object versions, snapshots, queues, and caches must inherit the tenant policy. Cross-region replication should require explicit customer or failure-policy authorization. Make backup retention, deletion delay, and key location queryable. Include email, analytics, and logging vendors in the data-flow map and contract review.

Step 4: Make availability and disaster recovery explicit

If strict residency prohibits cross-region replication, a regional outage may mean paused writes, read-only service, or waiting for recovery. Put RPO, RTO, freshness, and acceptable loss into each residency package so customers choose the trade-off. Cross-region recovery requires authorization first, followed by records of the temporary region and return migration.

Step 5: Restrict operations and support access

Support staff, contractors, bastion hosts, and remote-debug tools may process customer data. Use least privilege, region binding, short-lived grants, and complete audit logs. Prefer redacted samples; production exports need approval and expiry. A Germany storage choice does not place every operator in Germany, so people and control-plane boundaries require separate verification.

Step 6: Provide verifiable evidence

Show the tenant policy, data classes, region, replication state, backup locations, keys, and exceptions in a customer portal. Continuously check the actual locations of buckets, databases, log pipelines, and service dependencies; block new writes and alert on drift. Audit exports should include time, policy version, resource, actor, and evidence source rather than one static compliance PDF.

Step 7: Design migration, exit, and communication

For a region change, assess impact and inventory data, then perform encrypted transfer, verification, dual-write, cutover, and old-copy cleanup. At exit, explain export format, deletion windows, backup expiry, and vendor retention. During incidents or exceptions, product, legal, support, and engineering should use one state machine to communicate impact, repair progress, and follow-up evidence.

High-quality sample answer

I would define residency as auditable storage, processing, replication, and human-access boundaries and inventory customer content, logs, backups, telemetry, and support attachments. After region selection, every write, asynchronous task, backup, key, and vendor integration reads the same policy; cross-region recovery needs explicit authorization. When strict residency conflicts with availability, offer pause, read-only, or delayed recovery choices and put RPO/RTO in each package. Before launch, exercise writes, replication, recovery, operator access, and exit. The portal should show policy versions and evidence, while drift immediately blocks and alerts.

Common mistakes

• Promising only the primary database region while ignoring backups, logs, caches, telemetry, and support attachments.
• Treating a cloud region name as a complete sovereignty or operator-access promise.
• Claiming cross-region disaster recovery has no compliance or RPO impact.
• Providing a static compliance PDF without checking actual resources and vendors continuously.
• Letting customers switch regions instantly without handling historical copies, dual-write, and deletion evidence.

Follow-up questions and responses

Follow-up 1: What happens during a regional outage under strict residency?

Offer paused writes, read-only service, or local recovery according to the selected RPO/RTO. Cross-region recovery requires pre-defined authorization, temporary-region, encryption, and return-migration evidence; high availability does not imply cross-border replication.

Follow-up 2: Are logs and telemetry customer data?

Classify by fields and processing purpose. Logs containing tenant identifiers, request content, or linkable personal data belong in the policy. Pure aggregates can be assessed separately, but “telemetry” is not an automatic exclusion.

Follow-up 3: How do you measure success?

Track policy adoption, time to detect resource drift, exception closure, audit-export success, migration completion, and availability impact. Renewal and audit feedback are outcome signals; a count of sales promises is not.

Follow-up 4: Does a cloud-provider guarantee equal a SaaS guarantee?

No. Provider regions, dependencies, and personnel controls are capabilities. The SaaS still has to verify its routing, backups, vendors, keys, and support process and state contractual exceptions.

Follow-up 5: How can a customer prove there was no cross-region replication?

Provide policy-versioned resource inventories, replication and backup state, key locations, access audits, and drift alerts, with agreed sampling by a third party. Evidence must trace to actual resources and time windows.