I've heard these words so many times, it's refreshing to see someone dig into why bucket policies aren't a cure-all.
As for "Why not use synchronous deletion?" — regarding the pitfall there, what about a WAL? I.e., you WAL the deletions you want to perform into an object in the object store, perform the deletions, and then delete the WAL. If you crash and find a WAL file, you repeat the delete commands contained in the WAL.
(I've used this to handle this problem where some of the deletions are mixed: i.e., some in an object store, some in a SQL DB, etc. The object store is essentially being used as strongly consistent storage.)
(Perhaps this is essentially the same as your "delayed queue"? All I've got is an object store though, not a queue, and it's pretty useful hammer.)
First time I’ve seen one of these. That’s actually a better way to advertise your product than putting it at the end.
The mark phase can be done in parallel building many bloom filters for the files/objects found.
Then the bloom filters are merged (or'ed together essentially) and then a parallel sweep phase can use the bloom filter to answer the question: is this file/object live?
The bloom filter then answers either "No" with 100% certainty or "Maybe" with some probability p that depends on the parameters used for the bitset and the hash function family.
The expensive portion of the mark and sweep for the object store is the mark phase, not the storage of what's been marked. 100s, 1000s, or even millions of live objects wouldn't hardly take any space to keep in a remembered set.
On the other hand, querying the S3 bucket to list those 1M objects would be expensive no matter how you store the results.
But this does tickle my brain. Perhaps something akin to the generational hypotheses can be applied? Maybe it's the case that very old, very young, or very untouched objects are more likely to be garbage than not. If there's some way to divide the objects up and only look at objects whose are in "probably need to be collected" regions, then you could do minor fast sweeps semi frequently and schedule more expensive "really delete untracked stuff" infrequently.
Sometimes it's too expensive to mark in place, even if it's a bit that you need to write to disk and keeping a set of references may be prohibitive (or the structure holding the references is mostly/effectively immutable).
If it's all memory and mutable it doesn't (normally) really matter, but when it's not, you ideally would have some mechanism to move the code to where the data is, rather than stream the data to where the compute is (it is really wasteful for large scale data processing).
In any case, you would not be moving/scanning the files themselves, but the metadata is what you want to read for the mark phase.
The article if I understood correctly implies that the files and the metadata of the files (Kafka queues and so on) are separate, so presumably, the metadata is much much smaller than the data itself, but still potentially large.
For example if you had a large scale content addressed store (think a massive version of git's blob storage), you typically add to something like that and keep a few mutable root references to start your GC from to seed a mark/sweep.
Following the git example, the roots would be the branches, tags and reflogs, and the metadata you scan the transitive closur of the trees that are reachable from those (simplifying a bit) but not the file blobs themselves.
I use git as an example because a a CAS lends itself very well to large scale distributed systems because you can reason about it as an immutable data structure, but you can still change it effectively with sane semantics.
They could even use cost allocation tags to predict if a bucket or group of buckets should be scanned if it's growing unexpectedly. Cost isn't a perfect metric but there's definitely signal there.
Keep compacting files at some regular cadence `t` and keep a bucket policy to delete files older than `t+delta+buffer`.
Then have an alarm for files older than `t+buffer`
