Friendster is one of the largest social network sites on the web. it emphasizes genuine friendships and the discovery of new people through friends.
Friendster – Scaling for 1 Billion Queries per day
Dual x86-64 AMD Opterons with 8 GB of RAM
Faster disk (SAN)
Traditional 3-tier architecture with hardware load balancer in front of the databases
Clusters based on types: ad, app, photo, monitoring, DNS, gallery search DB, profile DB, user infor DB, IM status cache, message DB, testimonial DB, friend DB, graph servers, gallery search, object cache.
No persistent database connections.
Removed all sorts.
Don’t go after the biggest problems first
Optimize without downtime
Moved sorting query types into the application and added LIMITS.
Range on primary key
Benchmark -> Make Change -> Benchmark -> Make Change (Cycle of Improvement)
Stabilize: always have a plan to rollback
Work with a team
Assess: Define the issues
A key design goal for the new system was to move away from maintaining session state toward a stateless architecture that would clean up after each request
Rather than buy big, centralized boxes, [our philosophy] was about buying a lot of thin, cheap boxes. If one fails, you roll over to another box.
- LiveJournal Architecture
- Wikimedia Architecture
- Feedblendr Architecture – Using EC2 To Scale
- GoogleTalk Architecture
- New Relic Architecture – Collecting 20+ Billion Metrics A Day