DEV Community: Think Software

Design Twitter — Microservices Architecture of Twitter Service

Think Software — Fri, 02 Apr 2021 06:22:51 +0000

Twitter is an online social networking service where users post and read short messages called “tweets”.

Most candidates try to design Twitter as a monolithic service in System Design Interview. If you check several existing online resources, they also try to design Twitter as a monolithic service. However, in our opinion, designing a gigantic service like Twitter as a monolithic service shows that the candidate lacks experience in designing distributed systems. Nowadays, it is a norm to design distributed systems in terms of microservices and even lamdas (or functions). No one is writing a new service as a monolithic service and companies are gradually converting their big monolithic services to a set of microservices. Hence, the candidates should discuss Twitter system design as a microservices architecture.

Here, we will discuss the high-level design of the Twitter service. The Twitter service comprises several micro-services as follows:

Tweet Service
User Timeline Service
Fanout Service
Home Timeline Service
Social Graph Service
Search Service

The following is the architecture of different logical components or micro-services in the Twitter service. Please note it is not an architecture of physical components. Also, we are not showing LB in front of each micro-service here for the sake of simplicity.

If you are interested to know more, you can checkout out the below videos where we are discussing the microservices architecture of Twitter in greater details:

For greater details on the microservices architecture system design of Twitter service, check the chapter on the Twitter System Design in Distributed System Design Interviews Bible.

This is a great resource to not just improve your distributed system design skills but also to ace your distributed system design interviews and targeting level L5+ in companies like Facebook, Google, etc. The book/course is still in-progress work. There are already quite a few chapters discussing the design of TinyURL, Twitter, Distributed Cache, Uber, Whatsapp, Netflix, Dropbox, etc. We will be adding more chapters soon.

The course also includes a section on mock system design interviews. This is a great resource because it will provide you the experience of an actual distributed system design interview. More mock system design interviews are being added as well.

How to Ace Object-Oriented Design Interviews

Think Software — Tue, 29 Dec 2020 05:11:54 +0000

Most candidates are afraid of object-oriented design interviews. The reason is that they do not understand how to tackle such interview questions. Some commonly asked object-oriented design interview questions include:

Design a Parking Lot System
Design an Elevator System
Design a Traffic Controller System

When an interviewer asks such a question, you need to understand first what he wants, what he is looking for in the candidate. And so, you need to first discuss all the requirements of the system before jumping to go and design it. Don’t assume anything on your own but specifically clear out every possible detail with the interviewer first in the first 5 to 10 min since this type of question is usually vague question. In general, you need to understand the following:

When an interviewer asks you this question, the first thing he is looking for is your requirement collection expertise. Whether you can clearly list out all the possible requirements and whether you can scope the problem into something that you can solve in 30–45 min.
Another thing that the interviewer may be looking for is your design skills, especially object-oriented design. He is looking for how well you can design the whole system in terms of components and classes. How you will model the system (such as parking lot or an elevator system) into different classes, identify constraints and design interfaces. How well-versed you are in object-oriented design concepts like abstraction, encapsulation, inheritance, and polymorphism, etc. Can you define the links and associations between the classes or objects in the system or not?
Another thing you need to consider is that when you are designing such a system, you should be discussing the design in terms of different design patterns. The design patterns are a well-described solution to the most commonly encountered problems which occur during software development. These represent the best practices used by experienced object-oriented software developers. This shows the interviewer about your experience in object-oriented design and analysis and provides positive feedback to your overall interview performance.
The interviewer also looks for whether you can identify different object-oriented design patterns or programming patterns while designing the system.
Sometimes the interviewer present you with a situation to evaluate how you can tackle concurrency in your design. E.g. In a parking lot design question the interviewer can suggest that the parking lot has two or more entrances or exits.
Sometimes he gave you some requirements about the system (e.g. selecting a parking spot near the entrance in the parking lot system design question) to see how you can figure out an optimal solution for the problem
This type of question is not a distributed system design question and so you should not try to solve it as a distributed system design unless you have clearly discussed this with the interviewer in the requirement collection phase. If you try to solve it as a distributed system design question, then an interviewer can interpret it as you have not sufficient experience to scope a problem and instead of simplifying, you are over-complicating the problem.

If you are interested to know more, you can check out the below video where I am discussing the design of a parking lot system in more detail.

If you are looking for a great resource to not just improve your distributed system design skills but also to ace your distributed system design interviews and targeting level L5/L6 in companies like Facebook, Google, etc. then you should check “The Distributed System Design Interviews Bible”.

Elevator System Design — A tricky technical interview question

Think Software — Mon, 28 Dec 2020 06:03:43 +0000

An Elevator System Design interview question is one of the best interview questions to gauge the candidate’s grasp on the fundamentals of Computer Science. In addition, this can be extended in many different directions, making it an ideal problem to see how the candidate thinks. It’s easy to make it an object-oriented design problem. It can be used to discuss different data structures that will help in the implementation. If needed, it can be made even more complicated by adding multiple elevators serving the building, where a request button summons the most appropriate elevator. That is another nice optimization problem. But the core single elevator problem is often good enough to judge the ability of a candidate to see different trade-offs inherent in any design

Requirements:

As always when an interviewer asks this question, it is always better to first understand what he is really looking for in the candidate. The best way to find out is to collect the requirements first.

An elevator can move up, down or standstill.
An elevator can transfer passengers from one floor in a building to another floor in the minimum time possible.
Elevator door can only open when it is standstill in a floor (i.e. not moving).
Let’s first discuss the number of floors that a building can have. The tallest building in the world is Burj Khalifa and it has around 163 floors. Let’s just assume that our system has 200 floors, which is still far greater than what the tallest building has. We cannot just assume some arbitrarily large number. When we are gathering requirements, we need to make sure that we are still collecting some reasonable requirements.
Burj Khalifa has around 57 elevators. We can assume in our system we have around 100 elevators.
Then there are some requirements related to each elevator like: a. Number of passengers / Load on the elevator b. Moving speed of the elevator
Now fourth requirement is about what we would like to minimize. a. Do we like to minimize the wait time of the passengers? b. Or do we like to minimize the overall wait time in the system?
You should also discuss with the interviewer that whether he would like to have different operational zones or sectors in the elevator system. A zone is the set of floors that are covered by a set of elevators. E.g. In our case of 200 floors and 100 elevators, we can, e.g., divide all the floors into 4 zones: · From 1–50: operated by 25 elevators · From 51–100: operated by 25 elevators · From 101–150: operated by 25 elevators · From 151–200: operated by 25 elevators Another way of zoning is to divide all floors into two zones (even and odd floors, etc.). When we use multiple zones in a building along with a set of elevators assigned to a zone then we can treat each zone independently from each other. If we use the first approach of 4 zones then our elevator design problem then boils down to 50 floors and 25 elevators. On the other hand, if we use the second approach of 2 zones (i.e. odd/even zones), our elevator design problem boils down to 100 floors and 50 elevators. If we need to decide whether to use zone or not and if yes then which zoning approach to use, it all depends on the waiting time requirements and speed of the elevators. Apart from the above requirements, there are some extended requirements like:
Triggering emergency alarm/brake
VIP or utility elevators

Object and Actors:

After collecting all the requirements, it is better to identify different objects and actors in the system. These objects and actors help us to identify the classes and interfaces that we need to implement an elevator system. In an elevator system, you can easily find the following objects.

Passenger
The elevator controller
Elevators
Then each elevator can have doors, button panels inside the elevators and then buttons
Floors and more.

Use Cases:

After identifying the classes and interfaces and the relation between them, it is also important to discuss different use-cases. The most important use-cases include:
· Calling Elevator Car: So, when a passenger wants to go up or down to a different floor he presses the up or down button to call the elevator. This requires scheduling an elevator car to go to the passenger floor.
· Move/Stop the Elevator
· Open/Close the doors
· Indicating moving direction
· Indicating elevator position: the floor where the elevator has reached. This is important to indicate to the passenger so that the passenger can get off the elevator at his destination floor
· Triggering Emergency Breaks
· Making an Emergency call

Algorithms:

Now, at this point, you should be discussing the different algorithms that can be used by an elevator system to dispatch the elevator car to a floor to serve a passenger. Common algorithms include:

First Come First Serve (FCFS)
Shortest Seek Time First (SSTF)
SCAN
LOOK

If you are interested to know more, you can check out the below video where I am discussing the design of an elevator system in more detail. The video also discusses how different algorithms are implemented.