Hacker News new | past | comments | ask | show | jobs | submit login

Huh what? Do you assume that code just works? Something's always breaking and there's always new features that people want. Editing tweets just barely became a thing. Which, btw, is the exact sort of feature that would be easy peg as trivial, but likely is not when you're running at Twitter scale. Before, a tweet had two states: created or deleted. Now it can have arbitrarily many states and possibly even interleaved ones. In a distributed system that's a lot more complicated.

Twitter runs its own infrastructure too. That takes a bunch of people. Computers don't just run themselves and they certainly don't provision themselves.

Traffic is likely super spiky too because of how Twitter reacts to current events. That probably requires cutting edge load balancing and real time code.

Not to mention all of the work getting everything translated and accessible to the entire globe. And of course moderating a site with millions of people so that literal civil wars do not start. And keeping in contact with various governments who probably contract each other and themselves on a regular basis. These are problems that are not as scalable as writing a bunch of code. You need real, physical people to handle these issues.

And now setting up a creator economy and their Clubhouse competitor.




I’m sorry I just don’t find the ability to edit tweets a groundbreaking new feature that is difficult to implement in 2022.


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.


Add 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.


oh 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.


I thought this was the site for people who realised that things are always much more difficult at scale.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: