Design a scalable CMP for GDPR, CCPA, and global regulations
Tests cross-domain privacy architecture at scale. Great answers: edge-based geo-routing, schema-per-regulation consent stores, signed preference tokens, and a postMessage vendor API. Red flag: plain localStorage or equating GDPR opt-in with CCPA opt-out.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
When serving a consent banner to a new visitor, which strategy avoids render delays and unauthorized tampering?
- a.Query a central database on each page load to determine the user's local regulation
- b.Resolve jurisdiction at the CDN edge and persist consent as a signed httpOnly JWTCorrect
- c.Use browser native geolocation API and cache the decision in a standard session cookie
- d.Detect region via client-side JS and store the choice in localStorage for fast access
Why? this is the answer
Resolving jurisdiction at the CDN edge prevents the layout shift caused by client-side detection, while a signed httpOnly JWT provides tamper-evident storage that third-party scripts cannot access. The most tempting distractor suggests client-side detection and localStorage, which introduces render delays and allows third-party scripts to overwrite consent state.
Just read this? Test yourself on what you have been reading.
Read the original → iabeurope.eu
- #privacy
- #system design
- #gdpr
- #cmp
- #web security
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on privacy — each one lists the topics its interview covers.
See open roles