Design a scalable CMP for GDPR, CCPA, and global regulations

WHAT THIS TESTS: This question tests whether you can design a globally distributed privacy system that balances legal precision with performance. The interviewer cares about edge computing, cryptographic integrity, schema design for regulatory variance, and secure cross-origin communication. They want to see you treat consent as a compliance-critical state machine rather than a UI afterthought.

A GOOD ANSWER COVERS: A strong answer hits four areas in order. First, geo-detection and routing. Propose IP-to-region lookup at the CDN edge, cached in a short-lived edge dictionary, so the first HTML payload already knows which consent experience to serve. Do not rely on client-side JS detection because it causes layout shift and flicker. Second, storage architecture. User preferences must be tamper-evident. Use server-side sessions backed by a regional database for durability, or issue short-lived signed JWTs stored in an httpOnly cookie. Plain localStorage is unacceptable because third-party scripts can overwrite it. Third, regulation-specific schemas. GDPR requires purpose-based granular consent with legal basis differentiation, while CCPA centers on opt-out of sale and service-provider distinctions. The data model must store purposes per regime, not a single global boolean. Fourth, vendor communication. Expose consent via a well-defined postMessage API gated by a strict Content Security Policy. Vendors should request consent status through a CMP stub, and the CMP replies with a signed payload. Avoid global JavaScript variables or cookie polling, both of which leak state and are vulnerable to race conditions.

COMMON WRONG ANSWERS: Red flags include suggesting a single boolean flag for all regulations, storing consent in unprotected localStorage, or using client-side geolocation APIs that delay rendering. Another mistake is proposing real-time database lookups on every page load instead of edge-cached decisions. Confusing GDPR legitimate interest with consent, or treating CCPA opt-out as equivalent to GDPR opt-in, signals weak privacy-law fluency.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle consent revocation propagation across ad-tech vendors in under one hundred milliseconds. They might probe your strategy for versioning consent strings when regulations change, or how you audit vendor compliance without blocking the main thread. Be ready to discuss data retention policies and automated deletion workflows.

ONE CONCRETE EXAMPLE: Imagine a user from Berlin. The CDN edge sees a German IP and injects a GDPR-specific bootstrap script. The CMP renders a TCF-aligned UI with twelve purpose toggles. The user consents to purposes one, two, and seven. The CMP writes a signed JWT containing the purpose bitmap and a timestamp to an httpOnly cookie, then posts a consent-ready event. An SSP vendor iframe calls the CMP stub via postMessage, receives the signed payload, verifies the signature against a JWKS endpoint, and only then initializes its auction logic. If the same user travels to California, the edge detects the new IP, serves the CCPA notice of right to opt-out, and stores a separate do-not-sell flag without overwriting the GDPR record.