Client Data Residency and Failover Drill (QA)

Client Data Residency and Failover Drill (QA)

1. 01

   Map every client data source to its physical region before the drill starts

   List each feed, its origin system, and the jurisdiction it sits in. A warehouse that spans three regions without a written map cannot be tested, only hoped about.

2. 02

   Define the failure you are simulating and write it down in one sentence

   Region loss, object-store outage, and query-engine saturation produce different recovery paths. Pick one per drill so the timing numbers mean something.

3. 03

   Snapshot row counts and query latency on the five reports clients open most

   Baseline before failover. Without a pre-drill number, a 40-second dashboard load after recovery looks acceptable when it used to be 3 seconds.

4. 04

   Force the failover and time it end to end with a stopwatch

   Distributed SQL layers such as CockroachDB replicate across regions, but replication lag and connection-pool reconnection still cost real seconds. Record the number, not the impression.

5. 05

   Run the client-facing reports against the standby path and compare to baseline

   Any report that returns different totals is a correctness failure, not a performance one. Flag it separately in the drill log.

6. 06

   Confirm object storage reads resolve from the alternate endpoint

   S3-compatible stores including Wasabi and Storj can be swapped at the endpoint level, but only if credentials and bucket policies were pre-staged. Test the swap, not the theory.

7. 07

   Write the recovery time into the client retainer agreement as a stated figure

   A tested number is a selling point. An untested claim is a liability the first time a client's Monday dashboard is blank.