Design a centralized consent platform: core components and database schema

WHAT THIS TESTS: This question evaluates whether you can design a regulatory-grade system rather than a simple UI toggle. Interviewers want to see that you understand consent as an immutable, jurisdictional, and granular governance problem, not just a database field. The focus is on auditability, version control, and real-time enforcement across multiple research contexts.

A GOOD ANSWER COVERS: First, architectural separation: distinguish the Consent Management Framework from the Consent Management Platform. The CMF is the governance layer that defines legal wording, jurisdiction rules, and revocation logic, while the CMP is the capture surface such as banners or in-app screens. Second, the Immutable Consent Log: an append-only ledger that records every consent event, revocation, and jurisdiction applied, functioning like a financial ledger that cannot be updated or deleted. Third, a granular schema: participants table for identity, research_activities table for surveys, interviews, and A/B tests with jurisdiction tags, wording_versions table for legal text hashes, and consent_records table linking participant_id, activity_id, wording_version_id, jurisdiction, timestamp, and event_type. Fourth, enforcement and sync: a processing logic engine that blocks activity when consent is missing, plus APIs that sync state to CRMs, CDPs, and analytics tools in real time. Fifth, revocation: a dedicated endpoint that writes a revocation event to the ICL and immediately cascades enforcement across all connected systems without erasing historical consent.

COMMON WRONG ANSWERS: A mutable boolean flag on a users table is the classic failure because it destroys audit trails and violates GDPR and POPIA requirements. Another red flag is conflating the CMF and CMP into one monolithic service, which makes cross-channel enforcement impossible. Proposing in-place updates to consent records instead of append-only events also fails because regulators require proof of what the user saw and when. Finally, ignoring jurisdiction-specific rules such as opt-in versus opt-out regimes shows shallow understanding of global compliance.

LIKELY FOLLOW-UPS: How would you handle consent for minors or vulnerable populations across jurisdictions? What happens when legal wording changes mid-study? How do you enforce consent in offline or third-party research tools? How would you merge consent profiles when the same participant is identified across multiple devices or email addresses? What is your retention and deletion strategy for the ICL itself?

ONE CONCRETE EXAMPLE: Imagine a participant in Germany opts into a survey but not an interview. Your schema records two rows in consent_records: one with event_type granted tied to wording_version v2.1 for surveys under GDPR opt-in, and another with event_type denied for interviews. Two months later the participant revokes survey consent. The ICL appends a revocation row with the same participant_id and activity_id, timestamped and hashed. The processing logic engine then suppresses any new survey invites and triggers an API call to the email platform to remove them from the survey segment, all without deleting the original grant record.

Source: ITLawCo Consent Management Framework