A user opens their account settings and clicks Delete my account. A confirmation dialog appears, the request returns successfully, and the interface shows a friendly message: “Your account has been deleted.” Has it? In the primary database, probably yes. The row is gone, or at least flagged. But in the seconds, days and months before that click, the same person’s data may have passed through a read replica, a Redis cache, a reverse proxy access log, an application log, a distributed trace, an APM agent, a SIEM pipeline, a Kafka topic consumed by several microservices, an analytics platform, a nightly warehouse load, a CRM, a support ticketing tool and a backup job. None of them necessarily heard about the deletion. The presentation starts with a deliberately simple web application and grows it, step by step, into the kind of distributed architecture many people in the room will recognise from their own work. Each new component arrives together with the technical reason it exists. After every step the same two questions come back: where does the personal data live now, and what would have to happen for it to disappear? Not every organisation runs all of these systems, and the architecture on screen is not a description of any specific company. The components are common patterns, and the propagation paths are the ones that naturally appear when those patterns are combined. The second half moves from diagnosis to design. It covers event-driven deletion and how it fails, privacy-aware logging, the particular difficulty of backups, data lineage as a practical engineering artefact, and a set of architecture patterns that reduce the number of places personal data can end up. The approach is technical throughout. Regulation appears only where it explains why the problem matters; the focus stays on systems, data flows and design decisions