He goes on a bit too long in this post, but I hope that the folks piling on to Blaine (who I don't know, but doubt is as incompetent as he's been made out to be) will read it. Scaling is not a simple problem, and many aspects of it are unique to the specific application. Given that Twitter runs on a not-very-fast framework built on a not-very-fast language and it rapidly became the largest site running that framework and language, one should really step back and ask, "is one IT guy going to be able to fix this?" and the answer is gonna probably be "no".<p>Premature optimization is the root of all evil, because it leads to micro-optimizations rather than architectural optimizations...since Twitter seems to be running an awful lot of boxes for shipping around tiny (really tiny) messages, I can't help but think they need some architectural optimizations. And that's something it takes the whole team to accomplish. One guy, particularly one guy without enough power to <i>make</i> people fix their code, is going to be helpless in the face of that--he'll keep throwing hardware and edge caching (edge in the sense of at the edge of the outgoing network rather than the traditional sense of close to users--but without a lot of awareness of the data or application) at the problem. Sometimes it'll work, sometimes it won't.<p>I don't know Blaine or the Twitter situation, but I do know that scaling on a very large scale is never simple (my previous business was focused on web caching and scalability, and I've dealt with several quite large scaling situations--for sites burning way more bandwidth than Twitter). People outside of the situation probably shouldn't decide they know what went wrong and who was to blame.