The word system design got pretty popular with software engineers ever since the FAANG and the FAANG-tier companies added an essential system design round in their interview process. I mean that’s how I came across the term.

Now the obvious question that would pop up in our mind is why the knowledge of large-scale system design is so important to these companies? I mean, if a candidate is a pro-coder, has the superpower of writing an O(1) complexity solution to any problem. Is it really necessary for them to have a good knowledge of system design too?

Okay, O(1) was a bit of a stretch but I think you got the point. We rarely get to design large-scale services from the bare bones in our day-to-day work as devs. Isn’t this too much to ask?

Let’s talk.


Why should you master designing large-scale distributed systems?

First thing, we will discuss why system design is important for software developers in general. Not just for the interviews but for your knowledge and career growth or maybe you want to start something of your own. You have a cool idea and want to design a system that would scale to millions of users. How would you do it?

Would you hire an architect or would you design it yourself? Of course, design it yourself. And to design a scalable system wouldn’t the knowledge of web/software architecture come in handy?

Having the knowledge of large-scale system design, in other words, the knowledge of web architecture, software architecture, cloud/distributed systems, gives you an edge as a software developer.

In your job when implementing new features, when designing a new module from the bare bones or when trying to scale the platform to deal with the traffic influx, you can make better decisions by applying your system design knowledge and stand out amongst your peers.

Let me walk you through the process of how software is typically developed from the bare bones and why application design knowledge is super important to developers.


Significance of system design – The importance of getting the application architecture right

The architecture is the base of an application and has to be carefully thought out to avoid any major design changes and code refactoring at a later point in time.

Speaking from experience, you don’t want to delve into re-designing stuff. It eats up your time like a black hole. It has the potential to push your shipping date further down the calendar by months, if not longer. And I won’t even bring up the waste of engineering and financial resources that is caused due to this.

It also depends on what stage of the development process we hit an impasse due to the hasty decisions taken during the initial design phases. So, before we even touch the code and get our hands dirty, we have to make the underlying architecture right.

A look at the architecture of our app should bring a smile to everyone’s face.

Though software development is an iterative and evolutionary process, we don’t always get things perfect on the first go. Still, this can’t be an excuse for not doing our homework.


An overview of the software development process

In the industry, architects, developers and product owners spend a lot of time studying and discussing business requirements. In software engineering jargon, this is known as Requirement Gathering and Analysis.

Once we are done with the business requirements, we sit down and brainstorm the use cases which we have to implement. This involves figuring out the corner cases as early as possible while fitting the Lego blocks together.

If you’re a fan of documentation, you might also want to write a high-level design document.

Now, once we have an understanding of the business requirements, use cases, corner cases and everything, it’s time to start the research on picking the right technology stack to implement the use cases.


Proof of concept

After we pick the fitting tech stack, we start writing a POC (Proof of Concept)

Why a POC?

A POC helps us get a closer, more hands-on view of the technology and the basic use case implementation. We get an insight into the pros and cons of the tech, performance or other technical limitations if any.

It helps with the learning curve if we’re working with completely new tech, also the non-technical people like the product owners and stakeholders have something concrete to play with and to base their further decisions on.

Now, this is only for an industry-scale product. If you are a solo indie developer or a small group, you can always skip the POC part and start with the main code.

So, we showcase the POC to the stakeholders and if and when everyone is satisfied, we finally get down to creating the main repo and our first dev branch on GitHub or any other similar code hosting service which the business prefers.

Phew!!

So, by now you would have realized how important it is to get the architecture right for the first time and the knowledge of web architecture to developers.

It shouldn’t be that only if you work for a really long while in the industry, you should look into software architecture rather it should be the other way around. As you learn to code, you should keep acquiring knowledge of architecture.

Well, this was about having the knowledge of system design to write your own thing. Now let’s find out what companies are looking for in a candidate during their system design rounds.


System design interview process

What companies are looking for in a candidate during a system design interview round?

Companies don’t expect us to be an expert in system design. The design discussions are open-ended, there is no perfect answer to a solution, no silver bullet, there are always trade-offs involved.

They want to gauge our thought process, they want to understand how we approach a design problem or do we immediately shift into panic mode when given a problem that we’ve never seen before.

In my system design course “Design Modern Web-Scale Distributed Applications Like a Pro” besides discussing how to design large-scale services in detail I’ve also discussed how to deal with a system design problem you’ve never seen before.

Getting back to our discussion on system design interviews. The problem that is given to us is intentionally underspecified. They want us to trigger a conversation and ask clarification questions on the problem like if there are any constraints, what kind of input the system has to handle, how much traffic the system should expect, traffic patterns and so on.

The interviewer as opposed to looking for a specific solution wants to see how we approach the problem as I stated above. And as we proceed with designing a system, we end up having a pretty detailed discussion with the interviewer on many different topics like scalability strategies, fitting technology, data handling strategies, design choices and so on. During the conversation, the interviewer tries to gauge the breadth and depth we have on the topic.  

We need to take ownership of the system design process, and the onus is on us to explain to the interviewer the design choices we make, the database type we pick, if there is a need for the message queue or any other component in the architecture and so on.   

Companies want to take engineers on board who they can trust to come up with a good solution for a problem without having a lot of supervision. They want engineers who understand the use case and the requirements well and come up with a fitting solution as opposed to being just driven by the buzzwords and the hype in the industry.

Let’s hear what Google has to say about the system design interviews.


Prepare for your Google interview – Systems design


The best way to perform in these interviews is to relax and think of the whole round as a session where you are designing the system for your own startup. Bounce your thoughts off the interviewer. Lead the design process, having a discussion with them.

The knowledge of designing large-scale distributed systems is one of the most important skills a software developer should have. I’ve developed numerous applications from the bare bones and the knowledge of the fundamentals has always helped me save time and a serious amount of money.

So, upto this point, we talked about why you should master system design. Time to talk about how to master system design?


The right way to educate yourself on system design

Most of the resources on the web, that I’ve come across, will tell you “Oh!! You have an interview at Company X it will take you a couple of weeks to prepare for the system design interview.” No, it won’t. I strongly disagree with that notion.

Designing large-scale distributed systems is an art. You can’t learn this in a couple of weeks. Trying to learn everything in a couple of weeks is a sure-shot way to fail your interview round. When the interviewer starts to dig deeper into specific components and design strategies, you’ll be standing there with a blank face. If you have a few years of experience in the industry, just the surface-level info won’t help you nail that system design interview round.

Okay!! So, what do I do?

Learning software architecture takes time, you have to continually educate yourself over time or you’ll end up overwhelming yourself.

Here are a few good resources that I recommend:

InfoQ is an amazing website for following high-level architectures of large-scale services. If you want to read about the infrastructure on which our apps run including things like DevOps and such thenewstack.io is a good resource for that.

You can also read the engineering blogs of large-scale internet services like Reddit, Facebook and so on. Just Google “engineering blog of service X”

I write about the architectures of large-scale distributed systems on this blog, here. Check it out.

Check out the Zero to Software Architecture Proficiency learning path, a series of three courses I have written intending to educate you, step by step, on the domain of software architecture and distributed system design. The learning path takes you right from having no knowledge in it to making you a pro in designing large-scale distributed systems like YouTube, Netflix, Hotstar, and more.

Well, Folks! this is it for now. I am Shivang. You can catch me on LinkedIn here. If you found the content helpful consider sharing the article with your network. Cheers!


You can subscribe to my newsletter to stay notified of the new content on the blog.