Twitter Faces Serious Problems
Posted by Nick O'Neill on May 22nd, 2008 4:36 PM
Twitter has been facing serious downtime problems over the past few days and it sounds like things may be getting worse. Not only is the company facing substantial scaling issues but they are also having general customer service issues. Twitter currently has a highly dedicated base of users that notice every second that the site is down. They also tend to voice their opinion on sites like Get Satisfaction, which I wrote about earlier today.
One such person is Ariel Waldman who has been harassed on the site. She was driven to post on Get Satisfaction following Twitter’s decision to not block a user who was making abusive comments toward her. The result has been a long interaction which resulted in Twitter’s decision to not take any action against the abusive user even though they have the right to.
Twitter is extremely expensive to maintain and without a top tier engineering team working on scalability full-time, it will be a challenge for the site to continue for much longer. Luckily the site has raised another $15 million in funding and will be able to buy more servers to handle the increasing load. This isn’t a long-term solution though and as Nik Cubrilovic points out, “Twitter will require not only a new architecture approach and a big injection of the best minds they can find.”
For now users will need to live with shoddy service. This isn’t going to work forever though. Something has to give and it will either be a larger competitor offering a scalable version or Twitter hiring a top-tier team of engineers to handle the problem. What do you think Twitter should do?
Add New Comment
Viewing 6 Comments
Thanks. Your comment is awaiting approval by a moderator.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Subtle difference, and surely some overlap in Twitter's case, but a common mistake in assessing Twitter's woes.
Do you already have an account? Log in and claim this comment.
They should take a page from the 37signals book and design the system's economics so that they are more than happy to take on more tweeters and scale up accordingly...
Do you already have an account? Log in and claim this comment.
I think it's a combination of a few things and now that the B round is closed, it should (has to) get better.
The very nature of raising money is extremely time consuming and mentally exhausting. I'm not taking anything away from Jack or Evan, but I think they (and their investors) would agree their time and energy would be better off spent on running Twitter instead of drowning in the "deal".
So I think the chronology of events makes sense. Jack and Ev were distracted to get the deal done, traffic continued to grow, which caused reduced attention to scale and performance and the site sucked. Which it did/does.
Notice. The deal was done last night and Jack made a post about downtime. Interesting timing.
What surprises me a little is that Fred and Albert at Union Square Ventures didn't step in a little earlier than they did to give a boost. I know all of that takes time to put together, and they have probably been working on it a long time, but I think it was a little late. I think the majority of heavy Twitter users would also agree.
At the same time, I'm really not worried at all about their business, their business model, or their uptime at this point. Why? Because I know that Union Square is behind them, and now the rumor is that Bijan and his crew at Spark Capital led this B round with USV. It makes sense; both of those companies have very solid portfolios, know what they are doing, and have been in the game for a while.
Now that the round is done, I think we'll see at least one or two top notch engineers join Twitter to help them grow (the right way).
Cudos to the Twitter team, Union Square, and Spark (I think)
Do you already have an account? Log in and claim this comment.
The application itself is actually not that complex (check the Slashdot threads on those issues). By applying a generative process (RoR and MySQL) the application was shifting too much of the load balancing and scalability issues away from the database to a higher, persistence level. This is simply engineering architecture malpractice at its best. I wish people would shift away from blaming RoR and actually identify the underlying problem.
I have seen similar things happen over and over again: the misperception that the LAMP stack is a sustainable platform and ready for abnormal growth rates is proven wrong by Facebook as well.
I simply believe that this is an architectural problem that roots in an excitement for a new technology. Don't get me wrong: it's great they tried, but at some point you should better stick with best practices or it will become very costly.
It would be sad to see a great idea like Twitter die because some people fell for some nice marketing speeches.
Here's my advice: get an architect who knows best practices inside out and implement the new system design instead of just fixing the symptoms.
Do you already have an account? Log in and claim this comment.
If scaling is not the problem, and just uptime, a freemium approach would make sense - free twitter accounts get x messages per month and paid members get x+y messages. That revenue can then go towards improving uptime (and scaling if needed).
The question is whether they think that they now have enough users to introduced paid services. Twitter is not exactly mainstream, mainly popular among the "digerati" in my opinion.
Do you already have an account? Log in and claim this comment.
Choice 1 is more expensive in terms resources short term but pays dividends long term. Choice 2 is faster to market and less expensive but over time serves to compromise the app.
I believe Twitter could manage a re-write by keeping the existing service running as "gimped" with patches and maintain their user base by being upfront about the new release plans and involving the community in the design process. With some VC they could sandbox the new application until ready for prime time!
I would like to be first in line by proposing they build into the new release an implementation which supports "read" flag which can be permanently set and supported in the API.
Add New Comment
Trackbacks