It's doubt it's the language. Sure, you might get more efficient throughput with another framework or language..but I think the core problem lies in how many p

It's doubt it's the language. Sure, you might get more efficient throughput with another framework or language..but I think the core problem lies in how many polling API connections they have. If their API is based on their core DB and not polling off a read only copy..they have a serious design flaw. API conections, given their nature of having to do a security check each time should be based on a slave copy read-only db which is near-realtime, or potentially dirty read but who cares, its for their API. The security lookup should be cached since you rarely change API security accounts more than once..if you do, then you update the caches.. etc. Granted I'm no expert, but it just sounds like they're overloading their DB with polling. Their web pages for each user should be cached since they're not really hit as much as the api or rss I dont' care what anyone says, having THAT many API connections constantly polling their DB along with what blane said about having to do authentication requests on every singel hit is taxing on any setup you can put together. Oh and if they have a single table holding all their tweets...big issues there. I'd have a 26 "tweet" tables, one for each letter of the alphabet and my switch in the business layer. Then simply ship tweets older than a month, or patition based on that.