This document summarizes how Twitter scaled its infrastructure to handle increasing traffic loads. It describes how Twitter distributed various components like message processing, delivery, and its MySQL database across multiple servers with a total of 32 CPU cores. Traffic was initially 200-300 connections per second but spiked up to 11,000 connections per second. MySQL queries increased to 2,400 per second. To handle the higher loads, Twitter heavily cached content with memcache and denormalized databases.

1. Scaling Twitter
Alex & Britt
(from Twitter)

2. Preconceived notions.

3. The story.

4. So, what happened?

5. What we did.

6. More boxes.
Not so many then. But now...
‣
Mongrels across 19 cores.
‣
Message processing/delivery across 16 cores.
‣
Jabber across 2 cores.
‣
MySQL on one big 8 core box.
‣
16GB+ for memcache across a bunch of
‣
machines.
‣ 32 cores total.

7. That’s a lot.

8. Why?
200 - 300 connections per second.
‣
Spiking at 800 connections per second.
‣
We’ve done 11,000 connections per second.
‣
MySQL has spiked to 2,400 queries per second.
‣
Alexa says we have a whole mess o’ traffic, and
‣
they’re not even seeing the API traffic.

9. memcache.

10. memcache.

11. memcache.

12. Cache the hell out of everything.

13. Denormalize.

14. find(:all,
:conditions => quot;substring(
truncate(id,0),-2,1) =
#{@fugly_dist_idx}quot;,
:limit => 10)

15. Starling.

16. Community.

17. YOU CAN HAS QUESTIONS