Soft delete, backups, caches and logs

Pressing delete on a photo you uploaded feels like a single, complete action. On the other end, it is usually the start of a small chain of separate steps, each owned by a different system, each with its own timeline, and each capable of not happening even when the first step - marking the file as deleted - definitely did. Understanding the chain is the difference between trusting a button and trusting a specific claim about what that button does.

The first step: usually a flag, not an erasure

When you delete a file through an app's interface, the most common thing that happens first is not the bytes being destroyed. It is a row in a database being marked - a deleted_at timestamp set, a status field flipped - while the underlying object in storage is untouched. This is called a soft delete, and it exists for good reasons: it is fast, it is reversible if something goes wrong, and it lets a support team recover an accidental deletion without restoring from a backup. From your side, the file has disappeared - it no longer shows in your account, no longer appears in search, no longer loads at its old URL if the application checks the flag before serving. From the storage system's side, nothing has changed yet.

The gap between those two facts is exactly where a privacy claim can be true in the interface and false about the bytes. A service is not lying when it says "your photo is deleted" if it means the record is soft-deleted and inaccessible through normal use. It is a much weaker claim than most people assume "deleted" means, and the distance between the two readings is the entire subject of this piece.

What actually removes the bytes

A hard delete - actually removing the object from storage - is a separate operation, and it happens on one of a few schedules depending on the service's design. Some run it immediately, triggered by the same action that flips the soft-delete flag, which is the version closest to what people assume "delete" means. Others batch it: a background job that runs nightly or weekly, sweeping up everything flagged for deletion and issuing the actual storage delete calls in bulk, because bulk operations are cheaper and easier to monitor than one-off calls scattered through the day. Still others rely entirely on an object storage lifecycle rule - the soft delete just stops the file being served, and the bytes expire later on whatever schedule the bucket's own rule specifies, which might be far longer than the interface implies.

None of these are inherently bad designs. The problem is that "deleted" collapses all of them into one word, and only one of the three matches the intuitive meaning.

Backups: the copy that exists specifically to survive deletion

Even a service that hard-deletes immediately on request usually has backups, and a backup's entire purpose is to survive things that happen to the primary copy - including a delete request, accidental or intentional. A nightly backup taken the day before you deleted a file will contain that file, and it will keep containing it until that specific backup itself ages out of the retention window, which is commonly somewhere between two and six weeks for routine operational backups, sometimes longer for compliance-driven retention.

This is not a flaw to be fixed - a service without backups loses everyone's data the first time a disk fails or an engineer makes a mistake, which is a worse outcome for you than a deleted file surviving in backup a few weeks longer than the interface suggests. It is a fact worth knowing rather than a fact worth being angry about: a genuinely deleted file, from a service that takes backups at all, is not gone from every copy the moment you press the button. It is gone from the live system, and it will be gone from backups once the backup rotation catches up, and a service that is honest about this says so - the honest version of a retention promise names the backup window, not just the live-system window.

CDN and edge caches: copies that outlive the origin

If a result was ever served publicly - a shareable result page, a preview image - it very likely passed through a content delivery network, which caches files at edge locations around the world specifically so repeat requests do not have to travel back to the origin server. Deleting the file at the origin does not automatically clear every edge cache holding a copy. Most CDNs respect a cache expiry time set when the file was first served, and until that time-to-live elapses, an edge node that already has a copy will keep serving it to anyone with the URL, entirely unaware that the origin has since deleted it. Some services issue an explicit purge request to the CDN as part of the deletion flow, forcing edges to drop their copies immediately; many do not, because purging is an extra API call that is easy to forget when building the delete feature and invisible when it is missing. The practical result: a shared link to a result can keep working for hours or days after you have deleted your account, purely because nobody told the CDN.

Logs: the copy nobody thinks of as a copy

Every request to a server generates a log line - the method, the path, the response code, often the full URL requested. If a photo or a result was ever served from a URL that encoded anything about it - a filename, an identifier, occasionally a signed token with information baked in - that URL sits in access logs on every server and every CDN node that handled the request, for as long as that operator retains logs, which is a policy set by infrastructure teams for debugging and security purposes and is very often not covered by the product's own privacy policy at all. Logs are the copy that nobody frames as a copy of your data, because structurally they are not: they are operational records that happen to contain a reference to your data as a side effect of recording what happened. That distinction is real from an engineering perspective and close to meaningless from yours, since a log line with a URL pointing at your photo is functionally a pointer to it for as long as both the log and whatever the URL resolves to remain valid.

What a truthful deletion promise actually looks like

Given all of this, a deletion claim worth trusting is specific about layers rather than making one blanket statement. It says something closer to: the file is removed from live storage immediately on request; it may persist in backups for up to six weeks, after which it is gone from those too; any CDN cache is purged as part of the same request; and access logs referencing the file are retained for the standard operational window, separate from the product's own data policy, with a stated duration of their own. That is a longer sentence than "we delete your data," and it is also the only version of the sentence that is actually checkable, because each clause names a system and a number rather than asserting an outcome.

A policy that just says "deleted" and stops there has not necessarily done anything wrong - it may simply not have thought through which of the four layers above it is describing, which is common and not evidence of bad faith. It is, however, a reason to read the sentence as covering the live system only, and to assume the other three layers behave however they behave by default, since the policy did not say otherwise.

Why this matters more for this category of upload than most

For an ordinary file - a document, a spreadsheet - the gap between soft delete and full erasure across all four layers is mostly a curiosity. For an intimate photograph, the gap is the actual risk surface, and it is why a service worth trusting with this category of upload, such as Rate Cock, is worth judging partly on how specifically it answers these four questions rather than on its interface alone. Knowing the four layers exist - live storage, backups, CDN cache, logs - turns a vague worry about "is it really gone" into four specific questions, some of which a service's own documentation will answer and some of which it will conspicuously not, and the silence on a specific layer is itself informative.

Related handling questions

The retention number itself, once you know to look for it, is usually expressed through the object storage lifecycle rule attached to the bucket holding the live copy - that piece covers how that specific rule works and why its setting is closer to ground truth than the policy sentence summarising it. What happens before deletion is ever requested - where the file goes and what gets checked along the way - is the earlier half of the same question, and the two pieces together cover a file's entire life cycle from upload to every kind of removal. A file sent to a human reviewer rather than a model follows a different retention model entirely, closer to a case file with its own handling than an automated storage bucket, and what a commissioned human review actually retains is worth reading on its own rather than assumed to match an automated tool's. Comparing services specifically on data-handling honesty, rather than features, is a real axis worth weighing - Penis Rater treats this as a genuine differentiator between otherwise similar tools, and it is one of the few comparison points that actually predicts something about risk rather than convenience. None of this applies to a measurement taken by hand and never turned into a file at all, which is the structural advantage Measure My Cock's method has over anything routed through a server - there is no deletion chain to reason about when nothing was ever uploaded.

The honest summary is that "deleted" is a word covering at least four different systems, each on its own clock, and a service that names all four is telling you something a service that names one is not.