What you'll learn: By the end of this lesson you will be able to translate the main GDPR ideas (lawful basis, data minimisation, storage limitation, erasure, access, transfers, impact assessments and breach duties) into backend design work: a data inventory, a retention rule per field, a deletion job that reaches every copy, a map of where personal data lives, and the evidence that shows it all works.
This lesson explains engineering consequences of a law. It is not legal advice. Which rules apply depends on who your users are, where you operate and what you do with the data, so confirm every decision below with a qualified lawyer or data protection officer.
A coat check promises three things: it holds your coat for the reason you gave, hands it back when you ask, and keeps no copy in a back room. A system holding personal data makes the same three promises to every person in its database, and a regulator may ask it to prove them. They are hard to keep once the "coat" is copied into a search index, a warehouse, a log line and a backup.
This lesson treats the General Data Protection Regulation (Regulation (EU) 2016/679, adopted 27 April 2016) as a source of design requirements. It builds on security for distributed systems and expands the short privacy section of ShopStream Stage 10.
Verified against the GDPR article pages on gdpr-info.eu, with the regulation's identity checked on EUR-Lex, on 2026-11-08. Article numbers are the regulation's own.
The core idea
GDPR is mostly a lifecycle problem: for every piece of personal data you must know why you hold it, where it is, how long you will keep it, who else gets it, and how you would find, export or delete it. If the system can answer those five questions from data and code rather than from memory, most of the regulation becomes ordinary engineering: a schema, a job, a log, a review.
Three examples run through the lesson: a minimal example (a keyed-hash pseudonym in Java), a realistic example (ShopStream's deletion design, in "In practice") and a failure example (a deleted shopper who returns after a backup restore).
The vocabulary you need
Article 4 defines the terms the rest of the text relies on:
- Personal data: "any information relating to an identified or identifiable natural person". A customer id or a courier's location trail counts, not just a name.
- Controller: the party that "determines the purposes and means of the processing". ShopStream, for its shoppers.
- Processor: a party that processes data "on behalf of the controller", such as a cloud host or payment provider, bound by a contract (Article 28).
- Pseudonymisation: processing so that data "can no longer be attributed" to a person "without the use of additional information". Recital 26 treats it as still personal data.
Anonymous information is different: Recital 26 says the principles do not apply to it, but tells you to consider the means "reasonably likely to be used" to identify someone, including cost, time and technology. "Anonymous" is a claim to test, not a label to apply.
The principles, as design requirements
Article 5(2) says the controller must "be able to demonstrate compliance", so evidence is part of the design.
| Principle (Article 5(1)) | What the text asks | What you build |
|---|---|---|
| (a) Lawfulness, fairness, transparency | Lawful, fair, transparent | A recorded basis per purpose; a notice that matches the code |
| (b) Purpose limitation | "specified, explicit and legitimate purposes", no incompatible reuse | A purpose on each field or table; review before reusing data |
| (c) Data minimisation | "adequate, relevant and limited to what is necessary" | Fewer columns, coarser values, no "might be useful later" fields |
| (d) Accuracy | Kept accurate | Rectification that propagates to copies |
| (e) Storage limitation | Identifiable form kept "no longer than is necessary" | A retention rule per field and a job that enforces it |
| (f) Integrity and confidentiality | "appropriate security", including against accidental loss | Access control, encryption, backups (Article 32, below) |
Lawful basis and consent
Article 6(1) lists six lawful bases: consent, contract, legal obligation, vital interests, a public-interest task and legitimate interests. Each purpose needs one, chosen and written down before processing starts, and the choice changes what you must support. Erasure grounds include withdrawn consent (Article 17(1)(b)); portability (Article 20) applies where processing rests on consent or a contract and is automated. For ShopStream, as a discussion starter only: orders plausibly rest on contract, tax records on a legal obligation (which can override an erasure request, Article 17(3)(b)), marketing email on consent.
Consent has engineering rules of its own (Article 7). You must be able to demonstrate it, so store who, which text version and when. A consent request inside a longer document must be clearly separable. Withdrawal must be "as easy to withdraw as to give consent", so a one-click opt-in cannot be paired with a letter-to-withdraw process. And consent is not freely given if a service is conditional on processing the service does not need.
Minimise first: protection by design and by default
Article 25 asks for measures "such as pseudonymisation" that implement principles "such as data minimisation" effectively, and, by default, processing only what each purpose needs, covering "the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility". In practice that is about defaults: store dashboards hide shoppers' phone numbers, courier location is kept briefly, analytics tables take pseudonymous ids.
Minimal example: a pseudonym
Logs and analytics rarely need a real shopper id. A keyed hash gives a stable pseudonym: repeat orders can be counted, but the value cannot be reversed without the key.
static String pseudonym(byte[] key, String shopperId) throws Exception {
Mac mac = Mac.getInstance("HmacSHA256");
mac.init(new SecretKeySpec(key, "HmacSHA256"));
byte[] tag = mac.doFinal(shopperId.getBytes(StandardCharsets.UTF_8));
return "p_" + HexFormat.of().formatHex(tag, 0, 8);
}A single-file demo calling it with a demo key (run on Java 26.0.1 locally; it uses only standard-library calls available since Java 17) printed:
shopper 1001 -> p_adf52e321cb0fe2f
shopper 1001 -> p_adf52e321cb0fe2f (same key, same pseudonym)
shopper 1002 -> p_230681091aad17a3
shopper 1001, other key -> p_476d28c8827bfcca (new key, no link to the old one)The key is the "additional information" of Article 4(5) and belongs in a secrets manager, apart from the data. Anyone with the key can recompute the pseudonym of any guessable id. The table also stays in scope, because Recital 26 treats pseudonymised data as personal data.
Retention and deletion: the hard part
Article 5(1)(e) means every field needs a retention rule: a duration, a trigger (order delivered, account closed) and an owner. Article 17 gives a right to erasure "without undue delay" on listed grounds: data no longer necessary, consent withdrawn with no other basis, a successful objection, unlawful processing, a legal duty to erase, or a child's data collected for online services. It also lists exceptions, including a legal obligation and the establishment, exercise or defence of legal claims (Article 17(3)).
So "delete the shopper" is not one DELETE. It is a fan-out to every store that holds a copy, and some copies must stay.
Figure 1. A data map: every box is a place a deletion must reach, or a reason it cannot. How to read this: the orders database is the source of truth and the other arrows are copies. The dotted arrow to backups is the one a delete job cannot rewrite. The payment provider is a separate processor.
The deletion job
A deletion request is a workflow with state. Requests under Articles 15 to 22 must be answered "without undue delay and in any event within one month", extendable by two further months where necessary, with the person told of the extension within the first month (Article 12(3)). That clock needs a tracked request, not an inbox.
Figure 2. The erasure workflow. How to read this: the middle block runs in parallel and each store reports back, so the privacy service can prove completion. The ledger is checked, not deleted, because accounting records may have to stay.
Three design points follow:
- Delete or anonymise, store by store. For rows a legal rule requires you to keep (invoices), strip the personal fields and keep the numbers. That only works if the ledger was designed without personal fields, as ShopStream's ledger is.
- Make every step idempotent and retryable, so a failed call cannot leave a half-deleted shopper.
- Treat backups as a design question. The regulation text does not prescribe a backup procedure. Common engineering choices are short backup retention so copies age out, a tombstone list re-applied after any restore, and per-person encryption keys that can be destroyed. Each has costs, and how far a backup must be erased is a question for your legal adviser.
Access, portability and transfers
Article 15 lets a person ask whether you process their data and receive a copy, with details such as purposes, recipients and the intended storage period. Article 20 adds portability in "a structured, commonly used and machine-readable format" where processing rests on consent or contract. One export job keyed by person across all stores serves both, and the Figure 1 map tells you which stores to include.
"Data residency" is an engineering word; the regulation's word is transfer. Article 44 allows transfers to a third country only if the chapter's conditions are met and people's protection is not undermined. Without an adequacy decision, Article 46 requires appropriate safeguards with enforceable rights, such as binding corporate rules or standard data protection clauses adopted by the Commission. For design, keep a region map: for each store in Figure 1, the region and provider, including backups, logs and the failover region of the multi-region plan.
Records, impact assessments and breaches
- Records of processing (Article 30): purposes, categories of data and people, recipients, transfers, planned deletion deadlines and a general security description. A small-organisation exemption exists but is lost for risky, regular or special-category processing.
- Impact assessment (Article 35): required before processing likely to create a high risk, especially with new technologies. Article 35(3) names large-scale profiling with significant effects, large-scale special-category data (Article 9: health, religion, biometrics and similar) and large-scale monitoring of public areas. It describes the processing, assesses necessity, proportionality and risks, and sets measures (35(7)).
- Security (Article 32): measures including pseudonymisation, encryption, timely restoration after an incident and regular testing.
- Breach notification (Article 33): notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours" after becoming aware, unless the breach is unlikely to risk people's rights. Processors must tell the controller without undue delay, and every breach is documented.
Processors need a contract (Article 28) that includes deleting or returning all personal data at the end of the service. Article 83 sets fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher, for infringing the basic principles, and up to EUR 10 million or 2% for some other duties.
A review gate for new fields
Figure 3. A review gate for new personal data. How to read this: every path stops the field, adds missing work or ends at "ship", and the record of processing is updated at release.
Trade-offs
| Decision | Gain | Cost | Wrong when |
|---|---|---|---|
| Short retention | Less to protect and delete | Lost history | A legal duty requires longer |
| Pseudonymous ids downstream | Lower exposure in logs and warehouse | A key to manage | The key sits beside the data |
| Per-person encryption keys | Destroying a key makes every copy unreadable | Key management, harder restores | Keys are backed up with the data |
The other side of this topic
On the front end, the same rules appear as consent banners, preference centres and account screens where a person can see, export and delete their data. A consent control that a keyboard or screen-reader user cannot operate is a design failure. The back end owes the interface a versioned consent record, a request status it can display and a clear error when a deletion is held for a legal reason.
In practice: erasing shoppers across ShopStream
This is the realistic example, an educational scenario on the course's running example. Every figure is illustrative.
This is a realistic scenario, not a case history.
The situation
ShopStream, the grocery marketplace, has about 10 million monthly active users in its illustrative end state, with shopper data in the orders database, a search index and a warehouse. Support deletes accounts with a script that clears the orders database only. A shopper requests erasure and later finds old orders in a store's partner export.
Starting architecture
Figure 1: a source of truth plus asynchronous copies, with no list of which copies exist.
Options considered
| Option | Cost | Risk |
|---|---|---|
| A. Extend the manual script | Quick | Forgotten stores, no proof |
| B. Central privacy service, one delete handler per store | A service and store-team work | Handlers drift out of date |
| C. Pseudonymous ids downstream | Re-plumbing pipelines | Pseudonyms stay personal data |
The decision
B, helped by C where cheap. Each store team owns a delete handler, and no new store ships without one (the gate in Figure 3). The ledger keeps entries without personal fields, courier location gets a short retention rule, and logs carry pseudonyms or ids only.
Rollout and verification
Roll out store by store, keeping each request "partial" until every handler reports. Verify with a synthetic shopper: place an order, run the full path, then search every store for its id and email. Alert on request age before the one-month limit, and add a CI check that every new table has a retention rule.
The 2 a.m. failure
After a database restore, deleted shoppers can sign in: the restore brought back accounts erased since the backup. Check the restored ids against the tombstone list from Figure 2, and re-run deletion for every tombstoned id before reopening writes. The lasting fix is a restore runbook that applies the tombstone list as a mandatory step, tested in a drill.
Figure 4. The design after the change. How to read this: one entry point, one handler per store, and a path from the restore runbook back to the privacy service.
Architect's notes
- Start with the data map, kept in the repository next to the schema, with purpose, basis and retention per field in a registry CI checks.
- Design the ledger without personal fields so legal retention and erasure do not collide, and keep personal data out of logs.
- Rehearse the unhappy paths: a deletion under legal hold, a restore, a breach notice inside 72 hours.
Common mistakes
- Treating pseudonymised data as anonymous.
- Deleting from the primary database only.
- One consent box for several purposes, or a withdrawal path harder than the opt-in.
- No retention rule, so data is kept "just in case".
- Leaving backups, logs and failover regions off the region map.
Key takeaways
- GDPR obligations become five lifecycle questions: why, where, how long, who else, how to delete.
- Each purpose needs a lawful basis chosen up front; consent needs a record and an easy way out.
- Erasure is a tracked workflow across every store, with legal exceptions, a one-month default clock and a tombstone list for restores.
- Chapter V regulates transfers; keep a region map that includes backups and failover.
- Records, impact assessments and a 72-hour breach duty need data the system must produce.
Practice exercises
Exercise 1 (45 min). Draw the data map for an app you know, with region and owner for each store.
Exercise 2 (1 hour). Write a retention rule (duration, trigger, owner) for each column of ShopStream's orders table and mark the columns you would remove under minimisation.
Exercise 3 (2 hours). Write the erasure workflow for a service with a database, a search index and a nightly warehouse load, including legal holds, retries and tombstones.
Related reading
- System Design: Security for Distributed Systems: encryption, access control and audit logs.
- ShopStream Stage 10: Secure, Observable and Ready to Run: the short compliance section this lesson expands.
- ShopStream Stage 6: Payments and the Ledger, Money Without Mistakes: a ledger without personal fields.
- System Design: Multi-Region and Disaster Recovery: failover regions.
Official documentation
- Regulation (EU) 2016/679 on EUR-Lex: the official text.
- Article 5, principles and Article 6, lawful bases.
- Article 17, erasure and Article 12, response times.
- Article 25, by design and by default and Article 32, security.
- Article 35, impact assessment and Article 33, breach notification.
- Article 46, transfer safeguards and Recital 26, pseudonymised and anonymous data.