Consent preference keeper
A small system that records every consent and withdrawal as an immutable event, answers a single question — may we send this to this person — for every sending system in the business, and keeps the evidence of how each answer came to be. It never infers consent. Seven posts on the same system — one diagram at a time — with a cost breakdown and an engineering reference at the end.
- 01
A consent preference keeper on AWS for a few dollars a month
The whole system on one page — an event log, a resolver and a propagator — built so that the answer and the reason for it survive together.
- 02
How a consent event gets recorded
What evidence has to be captured at the moment of consent, why the exact wording is stored rather than referenced, and how purposes are chosen.
- 03
How a send decision is resolved
The single question the resolver answers, how it is computed from events, the caching that makes it viable at volume, and why it must fail closed.
- 04
How a withdrawal propagates
Pushing a suppression to every downstream copy, why verification matters more than the push, and what to do about systems that cannot be pushed to at all.
- 05
How consent evidence holds up
What answering a challenge actually requires, what makes an evidence record credible, the genuinely difficult retention question, and the numbers worth watching.
- 06
What the consent preference keeper costs
About $2 a month. One Bedrock read per thousand resolutions is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.
- 07
Engineering reference: the consent preference keeper architecture
Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the schemas and the exact model id.
Frequently asked questions
- What is a consent preference keeper?
- A small serverless system that holds one authoritative record of what each person has agreed to receive, records every change as an immutable event with its evidence, and answers a single yes-or-no question for every system that sends anything.
- Why not just a flag on the customer record?
- Because a flag answers what is true now and loses how it became true. The question that gets asked is “why did you email me”, eighteen months later, and only an event history can answer it.
- Does it stop systems sending?
- It answers a question; it cannot intercept a send. The discipline that makes it work is that every sending system asks first, and that a failure to reach it means do not send.
- What happens on a withdrawal?
- It takes effect immediately in the record and is pushed to every downstream system that holds its own copy. The push is best-effort and is verified, because a suppression that silently failed is the failure that matters.
- What does it cost to run?
- A couple of dollars a month even at high query volume. See part six.