How to Approach System Design Questions.

One of the most important rounds in any top tech company is the System Design round. These round not only judge your knowledge as a software engineer but also your capability to effectively communicate. As system design round is nothing less than a brain storming session with your engineering team.

Designing a real world system is challenging, hard but also fun at the same time. There are a few key points to consider before approaching to solve the question.

Gather All the Information about the System.

One of the major reason people tend to do poorly on the system design round is that they fail to scope the requirement of the system they have been tasked to design. Now, System design interviews aren’t coding round where there is an exact output results in the correct answer. Here, the questions are open ended and answers depends on the candidates ability to justify the choices they made for designing the system. Any failure to understand the requirements will result in you wasting time developing for features that weren’t even required or not able to prioritise the important functional requirements of the system you have been asked to design.

So, The very first steps during the system design round should be to ask question that help you scope out the exact requirements and metrics expected of the system.

List down the features expected to be designed.

After you have gathered the functional requirements of the system. It’s important to list down the requirements . As these will play a very important role in how you would not only approach the system but also how your solution would be structured at the end.

It is also a good idea to estimate at this point the scale at which the system would be designed to run and make it clear at this stages important design questions like whether the system would be eventual consistent or have strong consistency or whether it is the availability that is more important than being consistent.

Define API Structure.

Now that we have our functional requirement cleared and listed. At this point we should start defining What APIs to build. What these API’s expect as input and what would be the expected output. It is generally a good idea to define the interfaces this early as it will ensure that you are on a right track to develop the system and that you have not wandered off.

If you are able to define the API structure with clarity . It would also imply that the requirements for the system were well understood.

Define The Database schema.

After, You have defined the API structure. The next thing the should be approached is how the data flows within the system. At this stage you should also be able to choose between the type of DB that would well serve your system requirement.

A few points to keep into consideration before designing the db.

  • Identifying the various component in the system.
  • Identifying how the data flows within the system.
  • The Type of DB that would serve the system requirements.

Understand the Technologies being used to design the system.

It is very important to know the technologies. You would be using to design the system. Every tech you would use will have its own set of pros and cons. Understanding these would help you justify your choices during the interview. Which is the most important aspect of these System Design interviews (as described earlier there is no one correct answer to these system design questions).

Start designing the system.

Now, We have our functional requirement clear. We have designed the APIs . We have described how data flows within the System. It is at this point that you should start designing the system.

A few points to consider during this phase.

  • Start off with a very high level design of the system. With just a few components that would be the core of the system.
  • An important aspect of these interviews are your ability to answer questions based on any scenario’s that the interviewer might put up. For example he may ask What the cache eviction policy may be ? or what would happen if certain component of the system fails.
  • Design a system that could not only scale but also be reliable under heavy load. You should be able to answer questions like how scaling could be done effectively.
  • Start driving estimations based on the metrics you would have calculated in the requirement gathering phase. Use this estimation to describe the core components of the system.
  • It is very important in this phase to actively communicate with your interviewer. Explain him your solution asks for feedback. Any suggestion he would give try and evaluate whether it fits into your solution. It is extremely important to be a good listener during this phase of the interview. As there is no one answer to the question.
  • Do not panic.

Improve and add more details to your design.

Now that you have the core components of the system ready. You can flex a bit of your knowledge here.

  • Add more details to your existing solution like discuss whether you need more than one db for cases like analytics or how would you scale up or scale down ?
  • How and what components will have caching and what caching policy would well suit in what cases ?
  • Does the application needs load balancing ?
  • Is there any single point of failure and if so what steps can be taken to prevent it.
  • Do we have redundancy in place ? What happens if a few server goes down
  • How is the performance monitoring in place ?

These are few key points which you should take into consideration before approaching any system design question. Remember there is on one clear answer to any system design question. It is very important to actively communicate with the interviewer while explaining your choices. In most cases, He may actually help you solving the question.

Leave a Reply