Design a globally compliant, low-latency research backend architecture

WHAT THIS TESTS: This question evaluates whether you understand that data residency is an infrastructure boundary, not a security configuration. Interviewers want to see if you can separate control planes from data planes, reason about the latency cost of compliance, and know when anonymization is sufficient for cross-border transfer versus when raw data must remain local.

A GOOD ANSWER COVERS: First, regional partitioning. You should propose region-local storage clusters for raw research data and PII, ensuring the primary copy never leaves the jurisdiction. Second, edge ingestion and compute. Place API gateways and initial processing in-region to minimize latency for participants, then run aggregation or feature extraction locally before any export. Third, cross-border data rules. Explain that only anonymized or differentially private aggregates can flow to a global analytics environment, and that pseudonymized data often still counts as personal data under GDPR. Fourth, control plane versus data plane. A global control plane can manage experiment configuration, feature flags, and metadata without touching PII, while regional data planes enforce strict residency. Fifth, operational mechanics. Mention region-aware routing with GeoDNS, infrastructure as code for consistent policy enforcement, and audit logging for data access.

COMMON WRONG ANSWERS: Proposing a single global database with row-level security or field-level encryption. This fails because GDPR and similar laws require logical and often physical separation within the region. Suggesting that tokenization or pseudonymization alone satisfies cross-border transfer rules. Another red flag is ignoring latency entirely and proposing that all requests round-trip to a central EU cluster. Finally, confusing data residency with data sovereignty and missing the need for local vendor or cloud region selection.

LIKELY FOLLOW-UPS: How would you handle a researcher in the US who wants to query EU participant data? What is your strategy for anonymization and preventing re-identification? How do you maintain consistency in experiment semantics across regions without moving raw data? What happens if a region goes offline and the global control plane needs to fail over?

ONE CONCRETE EXAMPLE: Imagine an A/B test running in Germany, Japan, and the US. You deploy regional Kubernetes clusters in Frankfurt, Tokyo, and Oregon. Each cluster writes event logs to a regional object store and database. A local aggregation job runs nightly to compute click-through rates and session summaries with k-anonymity guarantees. Only these summary statistics are replicated to a global BigQuery instance in the US. Researchers worldwide query the global instance, but if they need raw session replays, they must access the Frankfurt cluster through a regional bastion and leave an audit trail. The global control plane, hosted in the US, only stores experiment metadata and routing rules, never participant events.