> HN Disclaimer: WarpStream sells a drop-in replacement for Apache Kafka built directly on-top of object storage.
First time I’ve seen one of these. That’s actually a better way to advertise your product than putting it at the end.
Another possible mechanism for doing GC at scale (a variation on Asynchronous Reconciliation in the article) in some file/object store, is doing a probabilistic mark and sweep using bloom filters.
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.
What I see working extremely well, arguably in a setting where cost was not really an issue was a much simpler approach.
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`
> Why Not Just Use a Bucket Policy?
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.)