What does Delete actually delete? · slopware 101

slopware 101 · step 22 of 35

What does Delete actually delete?

by · 3 min read

Every field on a signup form is a promise you make without noticing. From the moment a value arrives, you are responsible for every copy of it, wherever it goes, for as long as it stays. That is the engineering side of privacy, and it comes down to two habits: collect less, and be able to delete what you collected.

The cheapest field to protect

Imagine a small marketplace for second-hand sewing machines. The first draft of the profile form asks for full name, phone, birth date, home address, a profile photo, and a photo of an ID card so sellers can be verified.

Go through the form field by field and ask one question: what decision does this field make? The birth date only confirms that the user is an adult, and a verified yes or no can carry that. The home address is only needed when something ships, and then for one order, not on the profile. If identity verification is actually needed, decide which evidence must be retained for this service and why. An outcome record may be enough for some workflows; retaining a full document should be an explicit requirement, not a default copied from a template.

That is data minimization. The cheapest field to protect is the one you never asked for. The second cheapest is the one you deleted as soon as its decision was made. Write the retention rule into the design, next to the field: what the field is for, and the event after which it goes. How long that is depends on your product and your obligations. What matters is that the rule is written down and that something actually enforces it.

Knowing where it lives

Now suppose someone asks to be removed. Before you can delete their data, you have to find it. Make a data map, a list of every place a person's data can land. For the marketplace it might look like this:

  • the users and listings tables;
  • the storage bucket with photos, plus the thumbnails your resize job wrote;
  • application logs, if they carry emails or phone numbers;
  • the email provider holding contact lists and sent messages;
  • analytics events tied to a user id;
  • CSV exports someone made for a spreadsheet;
  • backups.

Stop and write that list for your own app before reading on. Most people find at least one place they had not thought of, often an export or a third-party service.

A deletion workflow you can run

If people can ask you to delete their data, deletion is a function you have to be able to run, not an intention. A workable shape:

  1. Confirm that the request comes from the account owner, through the account itself or a verified email.
  2. Mark the account as pending deletion so nothing new is written for it, and sign it out everywhere.
  3. Run one job, kept in your codebase, that deletes or anonymizes the person across every place in the data map. For records that need to be retained, define the required fields, access restrictions and retention period separately. Removing a name does not necessarily anonymize a record if other fields still identify the person.
  4. Call the deletion APIs of third-party services that hold copies.
  5. Know your backup policy. Backups you cannot edit should age out on a schedule you have chosen, and any restore must reapply all deletions completed after the backup snapshot as well as resume pending ones. Maintain a restricted deletion journal for that purpose, with only the identifiers needed to prevent deleted data from reappearing.
  6. Record that a deletion happened, with a date and an internal id, without keeping the data you deleted.

Test the workflow the way you test anything else. Create a synthetic user and give them a photo, a listing, a message and an entry in an export. Run the job, then search every location in your map for that user's id and email. Compare anything you find with the documented retention rule. An internal deletion record may intentionally remain; an unexplained copy of the photo should not.

Ending things on purpose

The lifecycle also includes closing a product. Stop accepting new data, explain what happens to existing records, run the planned export or deletion steps, and retire the credentials and integrations that no longer serve a purpose. A site that no one maintains can still hold data even when its interface disappears.

None of this changes because a model wrote the upload handler. The data was kept the way somebody left it, and the people who trusted you with it have no field for who typed the code.