Chapter 32 — Privacy and data protection: reliability
Lesson map
Lesson 32 published. Map, example, EX094.
flowchart TD
N0["Learning outcomes"]
N1["32.1 Erasure as a series system"]
N2["32.2 Retries"]
N3["32.3 Persistent failures"]
N4["32.4 Independence assumption"]
N5["Lab — Reliability of erasure across five stores"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX094"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["32.1 Erasure as a series system"]
N2["32.2 Retries"]
N3["32.3 Persistent failures"]
N4["32.4 Independence assumption"]
N5["Lab — Reliability of erasure across five stores"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX094"]
[Learning outcomes]
|
v
[32.1 Erasure as a series system]
|
v
[32.2 Retries]
|
v
[32.3 Persistent failures]
|
v
[32.4 Independence assumption]
|
v
[Lab — Reliability of erasure across five stores]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX094]
Learning outcomes
You will (1) compute the reliability of a multi-store erasure; (2) improve reliability with retries; (3) relate reliability to rights compliance.
32.1 Erasure as a series system
Erasure succeeds only if every store deletes the data. In reliability terms, the stores form a series system: the probability of complete erasure is the product of each store's success probability. Zara estimates first-attempt success rates from logs: booking database 0.995, records 0.99, video archive 0.95, analytics 0.90 and the backup deletion flag 0.98. Multiplying gives 0.825, so roughly one request in six would leave data somewhere on the first attempt. She presents this as a reliability problem, not a legal technicality. Each extra system multiplies the chance of a miss, so reducing copies improves reliability as much as fixing any one deletion.
32.2 Retries
Many failures are transient: timeouts, locks, temporary network errors. Zara adds one automatic retry per store. If failures are independent, the probability that a store fails twice is the square of its failure probability. With one retry the overall probability of complete erasure rises to 0.987. Expected incomplete erasures per thousand requests fall from 175 to 13. The lab confirms the calculation. She notes that the remaining failures are more likely to be persistent problems, which retries cannot fix and which require alerts. Persistent failures need human follow-up.
32.3 Persistent failures
For the remaining failures Zara adds a dead-letter queue: requests that fail after retry are routed to an operator with details of the failing store. The operator investigates and completes the deletion manually, recording the outcome. She sets a target of resolving all such cases within seven days, well inside the one-month response period in Article 12(3). The design turns a silent failure into a visible task, which matters because an erasure that silently fails is worse than a slow one: the patient believes the data are gone.
32.4 Independence assumption
The retry calculation assumes independent failures, but failures can be correlated: if the analytics store is down, every request fails there at once. Zara adds monitoring for store availability and pauses erasure for a store during an outage, resuming afterwards. She also tests the system under simulated outages. Prof. Holm explains that reliability engineering for privacy uses the same tools as for safety: series and parallel models, independence checks and fault injection, and that legal rights depend on these technical details. She tests shared dependencies.
Lab — Reliability of erasure across five stores
# Erasure must reach five stores; each deletion job succeeds with its own probability. Effect of one retry.
stores = {"booking DB": 0.995, "records": 0.99, "video archive": 0.95, "analytics": 0.90, "backups (flag)": 0.98}
p1 = p2 = 1.0
for s, p in stores.items():
p1 *= p; p2 *= 1 - (1 - p) ** 2
print(f"all five complete on first attempt: {p1:.3f}")
print(f"with one automatic retry per store: {p2:.3f}")
print(f"expected incomplete erasures per 1,000 requests: {1000*(1-p1):.0f} -> {1000*(1-p2):.0f}")
Run with python3 lab_erasure.py. Verified output:
all five complete on first attempt: 0.825
with one automatic retry per store: 0.987
expected incomplete erasures per 1,000 requests: 175 -> 13
Worked example
Zara models erasure as a series system with 0.825 first-attempt success, raises it to 0.987 with one retry (175 to 13 incomplete per 1,000), routes persistent failures to operators and guards against correlated outages.
Synthetic case. Success rates are synthetic; GDPR Article 12(3) is real.
Errors and limits
Logs may overstate success if confirmations are not checked; verify deletion by reading back.
Exercises
- EX094 — Series reliability. Why is complete erasure a series system? Rubric: 3 = it succeeds only if every store deletes, so probabilities multiply;; 2 = mentions all stores;; 1 = parallel;; 0 = none.
- EX095 — Retry effect. How do expected incomplete erasures change with one retry? Rubric: 3 = from 175 to 13 per 1,000;; 2 = direction only;; 1 = wrong;; 0 = none.
- EX096 — Silent failure. Why is a silent erasure failure worse than a slow one? Rubric: 3 = the patient believes data are gone when they are not;; 2 = mentions trust;; 1 = equal;; 0 = none.
Synthesis
Chapter 32 engineers reliable erasure. Chapter 33 addresses safety and resilience.
Continue studying — chapter 32 of 50
← Chapter 31 (draft) · Course chapter index · Chapter 33 (draft) →