Twitter - Architecture and Scalability lessons

24,447 views

Published on

One of the seminar's i'd given at college a couple of years back!

Published in: Technology
0 Comments
61 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
24,447
On SlideShare
0
From Embeds
0
Number of Embeds
62
Actions
Shares
0
Downloads
728
Comments
0
Likes
61
Embeds 0
No embeds

No notes for slide

Twitter - Architecture and Scalability lessons

  1. 1. Twitter! Architecture and Scalability Aditya B 05IT04
  2. 2. WHAT IS TWITTER ?
  3. 3. Its addictive <ul><li>micro-blogging platform </li></ul><ul><li>text-based posts </li></ul><ul><li>140 characters in length </li></ul><ul><li>followers receive updates </li></ul>
  4. 6. Who uses twitter
  5. 7. Web Traffic <ul><li>Twitter’s web-based traffic </li></ul><ul><li>Plus Twitter's API Traffic which is 10x the Site’s </li></ul>
  6. 8. As it often happens..
  7. 10. Downtimes!! <ul><li>2008 </li></ul>
  8. 12. So why the problem ? <ul><li>Over 350,000 users. </li></ul><ul><li>The actual numbers are as always, very super super top secret. </li></ul><ul><li>600 requests per second. </li></ul><ul><li>Average 200-300 connections per second. </li></ul><ul><li>Spiking to 800 connections per second. </li></ul><ul><li>MySQL handled 2,400 requests per second. </li></ul>
  9. 13. What? Why so?? <ul><li>When a user Abhinav writes a simple “I’m hanging out with…” message, Twitter has two choices – </li></ul><ul><ul><li>PUSH the message to the queue’s of each of his 6,864 followers, or </li></ul></ul><ul><ul><li>Wait for the 6,864 followers to log in, then PULL the message. </li></ul></ul><ul><li>It is not as easy as it looks. </li></ul>
  10. 14. A 6000x multiplication factor <ul><li>D o you see a scaling problem with this scenario? </li></ul><ul><ul><ul><li>Scoble writes something boom 6,800 writes are kicked off. 1 for each follower. </li></ul></ul></ul><ul><ul><ul><li>Michael Arrington replies boom another 6,600 writes . </li></ul></ul></ul><ul><ul><ul><li>Jason Calacanis jumps in boom another 6,500 writes . </li></ul></ul></ul>
  11. 15. <ul><li>कितनॆ आदमी थे ? </li></ul><ul><ul><li>~ 350,000 सरकार् </li></ul></ul><ul><li>और् तुम् ? </li></ul><ul><ul><li>1 database सरकार् </li></ul></ul><ul><li>बहुत् नाइन्साफी है ! </li></ul>
  12. 16. Bottlenecks <ul><li>Single MySQL database </li></ul><ul><li>no monitoring, no graphs, no statistics </li></ul><ul><li>Abuses </li></ul><ul><li>Plan to partition in the future </li></ul>
  13. 17. SOLUTION ?
  14. 18. Caching <ul><li>Getting your friends status is complicated. </li></ul><ul><li>There are security and other issues. </li></ul><ul><li>So rather than doing a query, a friend's status is updated in cache instead. </li></ul><ul><li>It never touches the database. </li></ul><ul><li>This gives a predictable response time frame (upper bound 20 ms) </li></ul>
  15. 19. Partitioning <ul><li>Plan to partition in the future. </li></ul><ul><li>Currently they don't. </li></ul><ul><li>The partition scheme will be based on time, not users </li></ul><ul><li>Because most requests are very temporally local. </li></ul>
  16. 20. Abuse Prevention <ul><li>Bots crawl the site and add everyone as friends. </li></ul><ul><li>9000 friends in 24 hours. It would take down the site. </li></ul><ul><ul><li>Saraha </li></ul></ul><ul><li>Be ruthless. Delete them as users. </li></ul>9000 14 2 Following Followers Updates
  17. 21. Scalability -- Doing It Right <ul><li>Asynchronous event-driven design </li></ul><ul><li>Partitioning/Shards </li></ul><ul><li>Parallel execution </li></ul><ul><li>Replication (read-mostly) </li></ul>
  18. 22. Are we all doomed to go through this painful process when we are successful? <ul><li>Time-To-Market </li></ul><ul><li>Vs </li></ul><ul><li>Architecture </li></ul><ul><li>Good, Fast, Cheap - pick two </li></ul><ul><li>:P </li></ul>
  19. 23. LESSONS LEARNED
  20. 24. <ul><li>Talk to the community. </li></ul><ul><li>Treat your scaling plan like a business plan </li></ul><ul><li>Build it yourself </li></ul><ul><li>Build in user limits </li></ul><ul><li>Don't make the database the central bottleneck of doom </li></ul><ul><li>Make your application easily partitionable from the start </li></ul>
  21. 25. <ul><li>Optimize the database </li></ul><ul><li>Cache the hell out of everything </li></ul><ul><li>Most performance comes not from the language, but from application design </li></ul><ul><li>Turn your website into an open service by creating an API. </li></ul><ul><li>Their API is the single most powerful reason for Twitter's success. </li></ul>
  22. 26. References <ul><li>http://twitter.com/ </li></ul><ul><li>http://highscalability.com/ scaling-twitter-making-twitter-10000-percent-faster </li></ul><ul><li>http://www.slideshare.net/ Blaine/scaling-twitter </li></ul><ul><li>http://dev.twitter.com/ 2008/05/twittering-about-architecture.html </li></ul><ul><li>http://www.danga.com/memcached/ </li></ul><ul><li>http://geekandpoke.com/ </li></ul>
  23. 27. QUESTIONS
  24. 28. ADITYA <ul><li>http://twitter.com/arbitya </li></ul><ul><li>[email_address] </li></ul>

×