Architecture One-Pager

Consent & Privacy Service · Solution Architecture v1.0 · Amazon Web Services · Security & Identity Architecture · 2026-10

This platform is the system of record for permission and never for personal data: it holds what each person allowed, and the data stays with its owner, which must ask.

Everyone has used this system without being told its name. The cookie banner. The "manage your ad preferences" screen three taps into an app. The email footer that says unsubscribe and sometimes means it. The "download your data" button that mails a zip the next day. The "delete my account" flow that warns you it is permanent and then has to make it permanent across forty internal systems and sixty vendors that were each sent a copy of you years ago. The screens are easy. What is hard is that each of them is a claim about the behaviour of an entire estate, made to a person who has no way to check it, enforced by a company whose incentive is to use the data, and audited by a regulator who will ask what was permitted on a specific Tuesday eighteen months ago. A privacy programme that cannot answer that question in minutes does not have a privacy capability; it has a set of promises and a document describing them.

Hold permission, not people. Purposes are versioned entities with a lawful basis declared per jurisdiction, a retention period, and the explicit list of systems and recipients permitted to process under them — and that list is the authoritative fan-out for every withdrawal and every erasure, which makes the registry a correctness dependency rather than a catalogue. Every permission decision is appended to a per-region ledger that is never updated; current state is a disposable projection carrying the ledger version it was built from, and every answer the platform gives names that version. Purpose limitation is enforced where the data is read, through a decision API backed by in-process caches with a published staleness ceiling and a per-purpose fail-closed posture. Rights requests become durable, resumable cases that resolve the subject to every identifier they are known by and fan out to roughly a hundred targets, tracking four distinct states per target — instructed, acknowledged, attested, verified — with a suppression list guarding every path by which data gets back in, and sampled absence probing because an attestation is a claim and not a fact. The whole regional stack is repeated per jurisdiction with no cross-border replication and no failover, and only the registry, which holds no personal data, is global.

What it is, and what it is not

• The system of record for permission — not A central lake that copies personal data in so it can be deleted in one place
• Purpose limitation enforced at the point of use — not Filtering at collection, which cannot honour a later grant
• A ledger of decisions, append-only — not A consent table that is updated when someone changes their mind
• Erasure as a verified protocol with four states per target — not A DELETE with a return code
• Silence from a target treated as failure — not Silence treated as pending, so the case can close
• Completeness evidenced and its residual gap measured — not Completeness guaranteed
• Fail closed, with a named, approved, auditable set of exceptions — not Fail open because the decision path had a bad minute
• Residency enforced in the data path — not Residency asserted in a policy document and a region column
• UNKNOWN as a verdict the caller must handle — not UNKNOWN quietly coerced to ALLOW

The decisions that are the architecture

1. Permission is the system of record; personal data stays with its owner (ADR-01) — The platform knows what each person allowed. It does not hold their data. That one boundary is why erasure is an orchestrated protocol rather than a delete, why purpose limitation lives on the read path, and why the purpose-to-system map is a correctness dependency.
2. The identifier graph is centralised, and is the most constrained store in the design (ADR-02) — Proving an erasure reached every identifier requires knowing every identifier, which means building the most attractive target in the company. It is accepted deliberately, held per region, encrypted per subject, case-bound and audited per record read.
3. The consent ledger is the truth; current state is a projection (ADR-03) — Append-only, never updated, RPO 0. A grant after a withdrawal is two facts. Every current-state record and every decision names the ledger version it came from, which is what makes point-in-time replay a query rather than a reconstruction.
4. Lawful basis is per purpose version per jurisdiction, and widening re-asks (ADR-04) — The same purpose has different bases in different places, and a change that adds a data category or a recipient is a new purpose version requiring fresh permission. Modelling this as data rather than as review is what stops scope creep being invisible.
5. There is no default purpose; an unregistered one is rejected, not denied (ADR-05) — DENY for an unknown purpose would let a typo look like a lawful refusal. Rejection surfaces the real problem: something is processing data under a name nobody declared.
6. Purpose limitation is enforced at the point of use (ADR-06) — Collection-time filtering is cheap, irreversible and cannot honour a later grant. Read-time decision is correct and couples the hottest read paths in the company to this platform, which the next two decisions exist to make survivable.
7. Consent state is pushed to local caches with a published staleness ceiling (ADR-07) — The common decision is an in-process lookup; the ledger stays authoritative. Staleness becomes the central risk, so it is measured per enforcement point and bounded by a fifteen-minute ceiling whose breach is an incident.
8. Fail closed, with fail-open as a declared per-purpose posture (ADR-08) — Universal fail-closed makes this platform the ceiling on every product's availability. A declared exception set puts a legal judgement in a configuration field — so it lives in the registry behind two-person approval and is audited whenever it is relied on.
9. UNKNOWN is a distinct verdict the caller must handle (ADR-09) — Collapsing "no record" and "could not read the record" into one answer is how a broken read path becomes silent unlawful processing. The SDK contract test, not a promise, is what enforces it.
10. Erasure is a four-state verified protocol per target (ADR-10) — Instructed, acknowledged, attested, verified. Collapsing them into a boolean is how a case closes while data remains, and it is the single most common way a privacy programme is wrong about itself.
11. The erasure technique is declared per store, in advance (ADR-11) — Hard delete, crypto-shredding a per-subject key, irreversible anonymisation, or tombstone-plus-suppression. Immutable logs and columnar warehouses rule out some options, so the technique is registry data and part of the evidence.
12. Silence from a target is failure, not pending (ADR-12) — A target that neither acknowledges nor attests inside its window blocks the case and escalates to its named owner. The alternative — pending until a timer closes it — manufactures completed erasures that never happened.
13. The suppression list is mandatory on every ingestion and restore path (ADR-13) — Backups, replayed streams and vendor re-uploads will reintroduce erased subjects. One compact set of hashed keys, consulted everywhere data enters, is the only control that holds across all of them.
14. Residency is enforced in the data path, and consent metadata is personal data (ADR-14) — Regional stacks, per-region keys, no cross-border replica and no failover. A region's unavailability denies its own subjects' consent-based purposes, which is correct rather than a gap.
15. Evidence of an erasure survives the erasure (ADR-15) — The platform retains the minimum identifiers needed to prove a deletion happened, under a legal-obligation basis the subject cannot withdraw, and says so to the subject plainly instead of engineering the tension away.

Why this should still be right in ten years

The regulations will change, the cloud services will be renamed, and the consent UX will be redesigned twice. The parts of this design that should outlive all of that are the ones that are statements about where authority sits and what can be proved, rather than statements about products or statutes.

• Permission and data are different kinds of thing. A system that governs use without holding the data has a different failure mode from one that centralises the data to govern it. That distinction is older than GDPR and will outlast whatever replaces it; the specific rights, deadlines and bases are configuration on top of it.
• An append-only record of what was permitted. Every regulator, auditor, court and angry user asks the same question in the same shape: what were you allowed to do, and when. A ledger answers it; a mutable state table never will, however carefully it is backed up.
• Completeness is evidenced, not guaranteed. No platform can prove by inspection that another system deleted something. Designs that claim otherwise are claiming a guarantee they cannot hold. Measuring and publishing the residual gap is the only honest posture, and it does not depend on which systems are in the estate.
• The fan-out list is a correctness dependency. The hard part of deletion has never been deleting. It is knowing where the copies are. Any future version of this problem is still a registry-completeness problem wearing new technology.
• Residency is a property of the data path. Jurisdictional boundaries are getting stricter and more numerous, not fewer. A design whose boundary is enforced by routing and keys survives new jurisdictions as new deployments; a design whose boundary is a policy document does not survive the first audit.

Non-functional targets

Every target below is a stated assumption for this exercise, chosen so a reviewer can disagree with one and follow it to the decision that depends on it.

Scope

In scope

• Purpose and lawful-basis registry with versioning, per-jurisdiction basis, data categories, retention periods, and the purpose-to-system and purpose-to-recipient maps
• Consent capture for authenticated and unauthenticated subjects, withdrawal at parity with grant, and the strictest-wins merge on sign-in
• Append-only regional consent ledger with a rebuildable, version-stamped current-state projection
• Decision API with in-process last-known-good caching, UNKNOWN as a distinct verdict, and a per-purpose failure posture
• Withdrawal event stream with propagation lag measured per enforcement point against a published ceiling
• Rights cases for access, portability, rectification, restriction, objection and erasure, with proportionate verification and durable resumable orchestration
• Erasure fan-out with four states per target, declared per-store techniques, a mandatory suppression list, and sampled absence verification
• Residency enforced in the data path with per-region keys and no cross-border replication or failover
• Append-only tamper-evident audit, point-in-time consent reproduction, and records-of-processing generation from live configuration

Explicitly out of scope

• Being the store of personal data itself — the estate keeps its own data and asks
• Authentication and account management; the platform consumes identity and does not issue it
• Campaign execution, advertising delivery and the consent banner's front-end implementation
• Deciding which lawful basis a purpose has; counsel decides, the platform enforces and evidences
• Data discovery and classification across the estate — the purpose-to-system map is declared, and its incompleteness is a named risk
• Model retraining itself; the platform triggers it and records the exemption where a subject is not identifiable

What a four-week prototype should prove

The prototype's job is to falsify the three claims the design rests on: that a withdrawal reaches a realistic population of enforcement points inside the published ceiling while the system is busy, that a decision on the read path is cheap enough that product teams will actually call it, and that an erasure across heterogeneous stores can be verified rather than merely attested. Everything else in this package is a consequence of those three holding.

1. One region, one purpose registry holding 12 purposes across 3 jurisdictions, and 2,000,000 synthetic subjects.
2. Six enforcement points with real in-process caches, two of them deliberately pinned to an older SDK version.
3. Four target classes behind real adapters: a transactional table, an append-only log with per-subject keys, a columnar warehouse, and a mock third-party API that goes silent at random.
4. A ledger preloaded with 90 days of synthetic capture history, so replay is measured against a realistic partition rather than an empty one.

• Measure withdrawal propagation per enforcement point under a 50x capture burst and report the distribution rather than the mean: the ceiling claim fails if the slowest point is outside 15 minutes
• Put the decision call in the read path of one genuine product surface and measure the added p99; if it is not single-digit milliseconds on cache hit, read-time enforcement will be negotiated away in production
• Erase 10,000 subjects across all four target classes and verify absence independently, counting what the attestations claimed against what the probes found
• Rebuild the full current-state projection from the ledger and measure the replay rate, because the 60-minute RTO is entirely a bet on 20x real time or better
• Switch the regional decision API off and confirm the fail-closed posture actually holds at every enforcement point, including the two running the older SDK
• Run one point-in-time evidence query for a subject at an arbitrary past timestamp, including the notice text shown at capture, and time the whole path end to end

Open risks, carried rather than hidden

The reasoning behind every component and technology choice is in the Architecture Decision Record: 15 records across 5 areas, each with the alternatives that lost and what the choice costs.