Prompt and use cases
Design a multi-tenant Consent Receipt Ledger that records consent, withdrawal, and purpose changes while supporting audit queries. This prompt fits system design, privacy engineering, and platform infrastructure interviews. The key is modeling consent as traceable facts rather than an overwritable boolean.
What interviewers assess
- Whether you define consent events, purpose versions, data categories, evidence, and withdrawal semantics.
- Whether tenant isolation, append-only integrity, idempotency, and verifiable queries are designed together.
- Whether withdrawal propagation, delayed consumers, retries, and historical corrections are handled.
- Whether privacy minimization, auditability, query performance, and retention are balanced.
Questions to clarify before answering
Confirm whether the subject is an end user or enterprise administrator, and whether consent is scoped by purpose, data category, region, or processor. Ask about peak event volume, query dimensions, audit deadlines, cross-region storage, withdrawal immediacy, and downstream acknowledgements. Clarify machine-readable export, legal hold, deletion requests, and tenant-managed keys.
30-second answer framework
“I would use versioned purposes and an append-only event stream for grants, updates, withdrawals, and propagation outcomes. Writes are tenant-partitioned and idempotent; reads return effective state and an evidence chain at a chosen time. Withdrawals notify downstream processors through a reliable queue with retries and human review. Encryption, minimal fields, tenant keys, and retention policies limit exposure.”
Step-by-step deep answer
- Domain model: Define subject, tenant, purpose version, data category, consent source, language, timestamps, evidence text, and state transitions.
- Writes and integrity: Append events with a monotonic sequence and request idempotency key; use a hash chain or signatures against silent edits, while separating key rotation from tenant isolation.
- State reads: Build projections for subject-and-purpose queries while retaining event position, projection version, and evidence references.
- Withdrawal propagation: Publish withdrawal to downstream processors and record each recipient’s acknowledgement, retry, and final failure; “sent” must not mean “processing stopped.”
- Operations and governance: Partition data, tier storage, audit access, prioritize deletion versus legal hold, and provide tenant-authorized exports and pagination.
High-quality sample answer
I would split the ledger into an immutable event layer, rebuildable projections, and controlled evidence storage. Each event would include tenant, a non-reversible subject reference, purpose and version, data category, action, source, time, policy version, and request idempotency key. Original consent text or a UI snapshot would live in encrypted storage and stay out of ordinary queries. Tenants would have separate partitions and key scopes; events would append to a tenant sequence and use hashes and signatures to detect silent edits. The query service would read a projection for effective state at a selected time, then return the event position and evidence reference. Withdrawal events would enter a reliable queue and track acknowledgement per downstream processor. Timeouts or refusals would retry and escalate, with explicit states for recorded, sent, acknowledged, and failed. Projections could be rebuilt from the ledger for purpose-version changes and historical correction. I would validate tenant isolation, duplicate requests, out-of-order events, key rotation, withdrawal latency, export authorization, and deletion holds with tests and replay drills.
Common mistakes
- Storing only
consent=true, which erases purpose versions and withdrawal history. - Treating downstream notification success as proof that processing stopped.
- Replacing append-only events with an editable row, losing evidence of history changes.
- Putting identifiable subjects or tenant data in a global index, breaking isolation and minimization.
- Designing writes without out-of-order events, retries, projection rebuilds, deletion, or legal hold.
Follow-up questions and responses
What if a user clicks consent twice?
Deduplicate with a request idempotency key and event fingerprint while retaining meaningful source or UI-version changes. Return the effective state and preserve which requests were merged or ignored.
Does a purpose-version change require new consent?
Treat purpose text and version as immutable references. If a new version expands processing, create a re-consent-needed state; do not silently apply old consent to the new purpose.
How does the ledger support deletion requests?
Separate audit evidence that must be retained from deletable subject data, using non-identifying references and cryptographic erasure where appropriate. Legal hold takes precedence over ordinary deletion, with scope and exceptions recorded as controlled events.
How do you prove a query did not miss events?
Return the tenant sequence range, projection version, and event-check summary. An audit tool can replay the event layer at the same point and compare it with the projection.