3 ms·
Having an immutable ordered log + a single bit flag for "deleted" is radically more efficient than an arbitrarily mutable ordered log. ex: You could store ever
by insanitybit 4y ago
Having an immutable ordered log + a single bit flag for "deleted" is radically more efficient than an arbitrarily mutable ordered log.
ex: You could store every tweet compressed in S3 with a bitmap for which are deleted (a bit that can be cached forever). That assumes you aren't going to ever have to update the object in S3. Once you have to update it that entire design is horrible, you'll need something completely different.
Consider that there are thousands of tweets per second with significant fan out for reads. There's search, relationship data (did you @ someone? did your edit remove that @?), business analytics, and more.
- zarzavat 4y agoAdd to that deletion flag a tweet redirect ID. Redirect deleted tweets with the ID to new tweets seamlessly. Touch up the old code to account for all this. Now you can edit tweets with immutability intact. Also has the benefit that retweets and likes point to the old version, which is how it should be.
- insanitybit 4y agooh ok so now instead of 1 immutable bit that can be cached forever we have to store an id. Good news, instead of a wonderfully compressable bitmap you now have a bunch of uncompressable 128bit nullable uuids. Only a few thousand times less efficient! Oh and of course you now have a linked list structure you have to traverse every time you want to resolve a tweet. Cool. It's almost like this is hard.