Hacker News Reader

Comment by yan | Hacker News Reader

They essentially deal with millions of real-time messages, each of which have a fairly complicated relationship tree. These issues aren't so much a database problem as a message passing and queuing problem.

View on HN

Why can't you just pass this to X number of servers?

The simple answer is: In the beginning they thought Twitter would more like Livejournal and architected accordingly (not that LJ is the pinnacle of good architecture or anything but even so). Instead it turned out to be more like IM and rather than starting again they decided to hack it into working.

Although the downtime must be frustrating for users and the temptation to build the shiny-new-system-that-will-solve-everything nearly irresistible for developers, I think they probably made the right decision not to do this. They have a runaway hit on their hands. That makes the risks associated with rewrite way higher (and they're already way high). One thing that people often do is start a "next-gen" project with an "architecture" team to figure out the new thing while a maintenance team (often lower-status within the organization) works on the existing product. This is so consistently bad an idea, it's pretty much a red flag all by itself. If I were ever going to rewrite a successful system I'd insist that it be the original team doing it.

I also wonder whether Twitter's downtime doesn't psychologically reinforce the sense that everybody's using it so it must be valuable. Scarcity and all that.

One thing about Twitter does make me pause. Haven't they hired tons of programmers? What are they all doing?

Interesting, so its something to actually learn from in regards to initial design flexibility.

But if I might ask? Would re-designing the entire architecture to accommodate for its current use be a wise idea to solve their downtime issue? I am just curious

Reply on news.ycombinator.com