Client-side Load Balancers (clone)

Introduction

In the previous lesson, we conceived the design of Twitter using a centralized load balancer. All end-users requests go through the centralized load balancing infrastructure into different services. Although this method works, and we employed it in other designs, it may not be the optimal choice for Twitter. It is because Twitter offers a variety of services at a large scale and centralized load-balancers are more suited for monolithic applications. To understand the concept better, let’s understand the history of Twitter design.

The design history of Twitter

The initial design of Twitter included a monolithic (Ruby on Rails) application with a MySQL database. As Twitter scaled, the number of services increased and the MySQL database was sharded. With a monolithic application, such a design is a disaster because of the following reasons:

• A large number of developers work on the same codebase which makes it complex to update individual services
• The upgrade process of one service may lead to the breaking of another
• Hardware costs grow because a single machine performs numerous services
• Recovery from failures is both time-consuming and complex

With the way Twitter evolved, the only way out was many microservices where each service can be served through hundreds or thousands of instances.