Practical, Useful Solutions

  Google Docs High-Level System design Multiple users work on the same copy of the document. The document could be text, rich text, painting, drawing. Let multiple users collaborate on the same copy of the document. Functional Requirement Users can change a document at the same time without any conflict Users can give permission(view, editor) for a document Users can make import and export a document A user can add a comment to the document Could be a notification (Email, GCM notification) Design Constraint Concurrency : A lot of people are working on the same document Latency : People are working in different places and they connect throughout the internet, so there is a latency between each and every know clients or users when they are sharing the same document. 200M User, Daily active % 10 = 20M User  Average 1 MB usage  ~ 1MB x 20M user = 20 BP per day usage Google Docs users get a lot of storage space with their accounts, but it's not unlimited. Each account can have up to:

  Functional Req One to one or groups chatting Receipts / Statuses Online/Offline Sent Delivered Read Multimedia Sharing Security Capacity Estimation  500M daily active users, average each user sends 40 messages daily = 20B daily messages Storage :  A message ~100 bytes * 20B = 2TB/day.  in 5 years : 2TB * 365 days * 5  year = 3.6PB We need to scale.  Bandwidth : 2TB everyday data per second : 2 TB /  86400 sec ~= 25 MB/s High throughput we can scale. High-Level System Design Logic Flow Heartbeating   UserA goes to load balancer.  LB will pick one the host behind based on load average or number of connections.  LB picks N1 - App server. Web socket connections bi-directional nature both server and the client can initiate a request.  At this point, while the UserA is not sending any data. They are just heart beating between them.  Why do we need to constantly heartbeat? Because the server knows that User A is still there and also User A knows the N1 - App server still there.  We can sto