Skip to main content

Twitter

What is it?​

img_472.png img_473.png

Requirements of Twitter’s Design​

img_474.png img_475.png img_476.png

High-level Design of Twitter​

img_477.png img_478.png img_479.png img_480.png

At most, how many hashtags can a Tweet have?

Details

The text limit is 280 characters in a Tweet. So, users can use the hashtag(s) such that text length (including plain text, any links, and hashtags) does not exceed the limit of 280 characters.

What is the need for the list_of_tagged_people in the /postTweet API?

Details

The system has to notify the people tagged in the Tweet.

img_481.png img_482.png img_483.png img_484.png

Which parameter in the viewHome_timeline method is the most relevant when deciding which promoted ads (Tweets) to be returned in response?

Details

The decision to send specified promoted ads is made on the user_location parameter. For example, the user belongs to the NewYork city, so most probably it gets promoted ads associated or originated in that region.

img_485.png

Details

To ensure the system is ready for the expected surge in traffic on New Year’s Eve and to avoid downtime, you would need to make several changes to the high-level design of Twitter. These include:

  • Caching: Implement caching strategies for frequently accessed data to reduce the load on the database servers.
  • Database Scaling: Add more database servers to distribute the load more effectively.
  • Load Balancing: Optimize the load balancers to ensure the increased traffic is evenly distributed across all servers.
  • Failover Strategy: Have a backup plan in place in case of a failure to ensure system resilience.
  • Sharded Counters: Increase the number of shards in its sharded counters to handle the expected burst of writes during interactions with tweets, such as likes and retweets. These changes aim to enhance the system’s ability to handle high traffic volumes, ensuring reliability and performance during peak times.

Detailed Design of Twitter​

img_486.png img_487.png img_488.png img_489.png img_490.png img_491.png img_492.png

img_493.png img_494.png img_495.png img_496.png img_497.png

img_498.png img_499.png img_500.png

Client-side Load Balancer for Twitter​

img_501.png img_502.png img_503.png img_504.png img_505.png img_506.png img_507.png img_508.png img_509.png img_510.png img_511.png img_512.png

Details

In a real-world scenario, a client-side load-balancing approach would be highly suitable for a cloud-based microservices architecture. In such a setup, each service could be deployed across multiple instances for scalability and reliability. Client-side load balancing allows the client (which could be another service) to make intelligent decisions on which instance to send requests to, based on the current load, latency, or other custom criteria. This approach reduces the need for a central load balancer, decreases latency by avoiding an extra network hop, and allows for more granular control over traffic distribution, which can be particularly beneficial in a dynamic environment where service instances can scale up or down frequently.

img_513.png img_514.png img_515.png img_516.png img_517.png