Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Tuenti: A Silicon Valley-like startup... in Spa...

Javier Maestro
September 26, 2011

Tuenti: A Silicon Valley-like startup... in Spain :) [2011]

This talk is a brief presentation of what is Tuenti, from the company history and structure to some fun-facts about how big we are and how much Spanish youth is using us to live their online social experience. At the end, I focus on the Backend Engineering in Tuenti and explain some general scalability aspects about how to build and evolve a web-app to sustain rapid growth.

Tuenti is the leading spanish invitation-only private social networking website that has been referred to as the "Spanish Facebook". According to ComScore, it is the most trafficked website in the country, having more monthly page views in Spain than Facebook and Google combined.

The site has rapidly grown in four years with millions of active daily users and was one of the most searched terms in Google's 2008 and 2009 Zeitgeists. We currently have more than 25 billion monthly page views and we are processing, storing and serving more than 2.5 million new photos every day (with peaks up to 5 million), with over 6 Gbps of image traffic at peak.

Javier Maestro

September 26, 2011
Tweet

More Decks by Javier Maestro

Other Decks in Technology

Transcript

  1. BIG Numbers +30 billion monthly page views +27k web requests/second

    +12Gbps peaks (including CDNs) +4Gbps just the datacenter +1000 servers
  2. BIG Numbers 50% of users on site daily, averaging 3

    sessions per day 82 minutes per day 20% of users use mobile features daily
  3. In the beginning… One or few servers for the entire

    application Monolithic structure Bottleneck: Database reads
  4. Cache Switch out heavy DB reads for light cache reads

    Significant reduction in DB load Typical page load has under 2 or 3 queries, and up to hundreds of cache reads Bottleneck remains the same as before
  5. Replication Master / Slave architecture Split up reads and writes

    Optimized configurations Bottleneck: dataset size
  6. Data Separation Divide your schema into logical blocks One cluster

    per data type More complicated to manage in code. Bottleneck: Overload on a given data type
  7. Data Partitioning Divide a single table into parts and spread

    them over several clusters Almost limitless scalability Not free – Code complexity increases significantly Bottleneck: dataset size (again)
  8. Cache Partitioning Partitioning does not need to be limited to

    databases Partitioned Memcached and frontend farms Improves internal network usage Cross partitioning scheme between cache and database
  9. Archiving Storing less-frequently- used data in alternative storage Keeps main

    table size within known limits Flexibility when choosing alternative storage
  10. Client-side routing Use browser logic to load balance over frontend

    farms Reduce server load Remove a potential SPOF