Prompt and context
Your B2B SaaS customers frequently delete data by mistake, but the platform only has full-database backups. Would you offer tenant-level point-in-time restore? Explain users, boundaries, risks, metrics, and a staged launch.
AWS notes that a multi-tenant partitioning model directly affects tenant isolation and selective restore complexity. CISA recommends offline, encrypted backups and regular recovery testing. The interview tests product judgment, not a promise that every timestamp can be restored without loss.
What the interviewer is testing
The interviewer wants to see whether you identify the real beneficiary and high-value scenario, distinguish export, undo, recycle bin, and point-in-time restore, define data and permission boundaries, and trade RPO, RTO, cost, support burden, and security risk. You should explain how recovery quality will be proven, not just show a button.
Questions to clarify first
- Which objects, tenant sizes, workflows, and compliance obligations are affected by deletion?
- Does a customer need a whole tenant, a subset of objects, or a few records?
- What are the current backup granularity, retention, tenant partitions, logs, and recovery drills?
- How will new data, external sync, permissions, audit, and search indexes behave after restore?
- What are the RPO, RTO, acceptable conflict, and willingness-to-pay targets?
- Who can request a restore, and is dual approval or support involvement required?
A 30-second answer
“I would first verify that deletion is frequent, costly, and not solved by export or a recycle bin. If it is worth doing, I would start with an administrator-requested isolated preview: create a temporary tenant-scoped space at a selected time instead of overwriting production, then let the customer choose an import after reviewing differences. I would validate value with restore success, RTO, conflict rate, isolation events, cost, and support tickets. I would pilot one partition model with controlled tenants, explicit non-restorable objects, approval, audit, and rollback boundaries before opening self-service.”
Step-by-step deep answer
Step 1: Validate the problem and alternatives
Analyze deletion incidents, support tickets, export usage, and business loss. Compare recycle bins, object versions, audit undo, export and re-import, and point-in-time restore by coverage and cost. If most incidents involve a few recent objects, improve the lower-risk alternative before productizing whole-tenant recovery.
Step 2: Define customers and the promise
Start with administrators, compliance teams, or high-value operators who have a clear recovery owner. Express the promise as measurable RPO, RTO, retention window, and object scope. State that external systems, live collaboration state, or permanently purged data may not return automatically.
Step 3: Choose restore granularity and interaction
Whole-tenant restore is simpler but destructive; object restore is safer but needs dependency graphs, conflict rules, and more implementation. Default to a read-only preview showing timestamp, object count, references, permission changes, and estimated duration, then let an administrator choose the import scope.
Step 4: Design isolation and consistency
The restore snapshot must be isolated from production, and other tenants must never enter the temporary space. Before import, check unique keys, versions, deletion state, cross-object references, search indexes, asynchronous jobs, and external webhooks. List objects that cannot be restored consistently instead of silently dropping or overwriting them.
Step 5: Handle authorization and dual confirmation
Only an explicitly authorized tenant administrator may request recovery; high-risk restores require a second confirmation, cooling period, or two-person approval. Write an immutable audit event, notify the tenant owner and security contact, and retain actor, timestamp, scope, source snapshot, and result summary.
Step 6: Model cost and capacity
Estimate snapshot storage, transaction-log replay, temporary databases, cross-region transfer, concurrent restores, and human support. Set tenant quotas, rate limits, and expiry cleanup. A free tier may get a shorter window or manual request, but pricing must not hide an infeasible recovery promise.
Step 7: Prove restore quality with drills
Regularly restore representative tenants in isolation and compare object counts, checksums, permissions, search, reports, and external synchronization. Track success, duration, conflicts, human intervention, failure causes, and cleanup time. CISA emphasizes continuously testing backup availability and integrity; a sales demo is not a recovery drill.
Step 8: Launch in stages and define exit gates
Start with one partition model, a limited window, and support-assisted recovery, then expand to more tenants and self-service. Gates include restore success, RTO, conflict rate, isolation events, unit recovery cost, and ticket reduction. If metrics miss the gate, pause requests or narrow scope instead of promising more timestamps.
Trade-offs and boundaries
Self-service versus assisted recovery
Self-service lowers support cost but raises mistake and authorization risk; assisted recovery handles complex conflicts but does not scale. Use preview, approval, and audit controls first, then open more self-service based on low-risk success.
Whole tenant versus object restore
Whole-tenant restore is shorter to build but may overwrite new customer data; object restore better matches intent but must handle references and ordering. Protect current data by default and require explicit scope confirmation.
Retention window versus cost
A longer window improves recoverability but increases storage, logs, and compliance cost. Tier by customer risk and plan, publish the available range and price, and keep sales promises within engineering capacity.
Failure drills and evolution plan
New data is overwritten after restore
Restore to a temporary space by default, show differences, and report conflicts before import. Preserve both versions or require human choice when merging is unsafe; never overwrite production directly.
A snapshot contains another tenant’s data
Test tenant filters, permissions, exports, and logs in isolation, including negative tests proving that an arbitrary ID cannot read a neighbor. Stop the restore entry point and start security response immediately if leakage appears.
Restore succeeds but search and reports disagree
Include indexes, caches, materialized views, and asynchronous jobs in the restore checklist, with rebuild status and availability messaging. Database row count alone does not prove a usable recovery.
Common mistakes and follow-ups
Mistake 1: Treating point-in-time restore as an undo button
Follow-up: What happens to data created after the selected time? Explain preview, differences, conflicts, and explicit import.
Mistake 2: Discussing backups without tenant isolation
Follow-up: How do pooled tables, separate databases, and sharded models change restore boundaries? How do you prove no cross-tenant data appears?
Mistake 3: Using average RTO to prove value
Follow-up: How do you measure tail duration, failure rate, human intervention, and unit cost?
Mistake 4: Ignoring external systems and permissions
Follow-up: What happens to webhooks, search indexes, role changes, and audit records? Which objects are explicitly non-restorable?
Follow-up questions and responses
When should you build a recycle bin before point-in-time restore?
If incidents mostly involve a few recently deleted objects and a recycle bin covers the loss, it is faster, easier to validate, and less conflict-prone. Evaluate point-in-time restore for high-value cases that cross objects or timestamps or exceed the recycle bin’s scope.
How do you explain that restore is not “going back in time”?
Explain source, timestamp, object scope, conflict rules, non-restorable objects, and duration; show a preview before execution. Replace a vague “complete recovery” promise with measurable RPO, RTO, and audit evidence.
Which metric would make you pause the launch?
Any cross-tenant isolation event should stop the feature immediately. Persistent RTO breaches, high conflict, inconsistent indexes after restore, or uncontrolled unit cost should also pause expansion until the cause and gate are fixed.