Hunter Johnson for Educative

Posted on Aug 22, 2022 • Originally published at educative.io

Simplify system design interviews with the RESHADED approach

#systems #career #programming #productivity

Do you want to know how to become better at system design interviews? Interviewing for a system design position can be daunting, but it doesn't have to be. RESHADED is a high-level system design interview strategy for designing just about any system from the bottom up.

Each letter of RESHADED represents an important aspect of system design to consider for your answers.

With a little preparation, you can ace your interview and land the job you want. If you're looking to take a step up in your career or want to impress your interviewers in an upcoming SWE interview, mastering modern system design practices is key, and one of the best ways to cover all your bases is to use RESHADED.

Keep in mind that this approach is not prescriptive and that there isn't a one-size-fits-all solution for every system that needs designing. However, you can still benefit from using RESHADED, even if you need to customize it to fit your own problem-solving style.

In this article, we'll be going over what the RESHADED approach involves, and then briefly touch on how understanding modern system design and its principles can help you become a better developer while achieving new heights in your career. We'll conclude with a quick recap, and provide some extra resources for you to continue your learning.

Let's get started!

We'll cover:

Why use RESHADED for system design interviews?
How understanding modern system design can help you in your career
Wrapping up and next steps

Why use RESHADED for system design interviews?

RESHADED stands for:

Requirements
Estimation
Storage schema (optional)
High-level design
APIs
Detailed design
Evaluation
Distinctive component/feature

The RESHADED approach is not only easy to remember but also a comprehensive way of approaching modern system design without getting bogged down in low-level details. This strategy helps you understand the entire system, from the hardware and software requirements all the way to the end-user experience.

A system design interviewer aims to assess how well you understand the system you're designing, not to drill down into the details of individual components. By using RESHADED, you can confidently walk your interviewer through the entire system and answer any questions they may have.

Each letter in RESHADED represents a key step you should take when answering a system design interview question.

Requirements

When designing a system, you first need to gather the requirements. During this step, you should ask your interviewer what the system needs to do and what constraints need to be considered. Your goal is to gather a complete picture of the functional and non-functional requirements for the system you are about to design.

Functional requirements are the system's core features and without them, the system won't function as the end user expects. For example, a functional requirement for an e-commerce website would be the ability to add items to a shopping cart.
Non-functional requirements don't contribute to the system's core functionality but are still important. For example, a non-functional requirement for an e-commerce website might be the system's availability even during high user traffic events like Black Friday.

Be sure to ask your interviewer clarifying questions as needed. They will notice the time you took to fully understand the requirements and will appreciate your effort.

You can even just ask them, "What are the functional and non-functional requirements for the system we're designing?"

Examples of questions you could ask your interviewer to gather requirements include:

What does the system need to do?
What are the system's key features?
What are the end user's expectations?
What are the system's constraints?

Estimation

At this step, you will need to estimate the hardware or infrastructural resources required to implement your system at a certain scale. This is a particularly important step because understanding the scale of the system will help you decide what technologies to use and how to optimize the system for performance. Estimations are vital to your design because they help you understand the feasibility of your project and ensure that the system will meet the end user's expectations.

Here are some of the questions an interview could ask to estimate the resources needed:

Estimating the number of servers: How many daily active users (DAU) do you expect to support?
Estimating the daily storage requirements: How many tweets are posted per day, and what is the percentage of tweets containing media?
Estimating network requirements: What is the maximum response time expected by the end user?

Storage schema (optional)

Articulating your data model is an optional step that you can choose to exercise if it seems relevant. At this step, you will define the structure of your data, which tables will be used, and what type of fields are in each table. This can be helpful for understanding the system at a more granular level and making sure that the system can handle all of the data efficiently.

Some problems where it may be useful to define your storage schema are:

When the data is expected to be highly normalized
When different parts of the data need to be stored in different formats
When there are performance or efficiency concerns around how the data is stored

Here's one example:

For a road network's storage schema, we might store information in a key-value store and graph database.

The key-value store would contain:

A road segment's ID
The serverID on which that segment is hosted
Boundary coordinates (latitude/longitude) as a list
List of neighboring road segment IDs (neighbors)

Graph database:

The road network inside the segment in the form of a graph

Once you're done gathering requirements, making your estimations, and outlining your storage schema, you're ready to start working on the actual design of your system.

High-level design

At this stage, you will start identifying the main components and building blocks used to build your system. This is considered the first step toward a complete design, and your main focus at this point will be to fulfill the functional requirements defined in the earlier stages.

When you're working on your high-level design, you may need to iterate and improve upon your original ideas as you gain more information. However, it's important to focus on the overall goal of the system you're designing. You don't want to dive too deep into the technical details at this stage because you want to use time efficiently.

Creating a diagram of your system can help you (and your interviewer) better visualize the overall structure and flow of the system. Diagrams can also help you identify any potential problems or issues with your design.

APIs

At this stage, you will be building interfaces for your service. This is where you will define the interfaces used by your end users to call various services within the system. Think of the functional requirements, and how you can translate them into API calls for your users.

For efficiency's sake, focus only on the parameters that are relevant to your system. If you need to fulfill a given request, you can always add more parameters in the future.

Here's an example of how you can translate functional requirements into a related API call:

Requirement #1: Users should be able to view all of the items in their inventory to select the items they want.

API Call: GET /items

This returns a list of all the items in the user's inventory.

Requirement #2: Users should be able to add items to their inventory and can keep track of what they have.

API Call: POST /items

This adds an item to the user's inventory. The body of the request should include both the name and quantity of the item being added.

Detailed design

At this stage, you are finalizing the design of your system, defining the workflow of your design, and its usage of different technologies. It is important to analyze the high-level design at this stage and discuss the details to improve the final design. This is also the stage where the non-functional requirements you gathered earlier will come into play. By adding components that meet the non-functional requirements, you are making your final design more complete and polished.

Fully outline the different components of your system and how they work together. For example, if you're using Cassandra, a type of NoSQL database designed to handle large amounts of data across many commodity servers, over MySQL, be prepared to briefly explain why and how Cassandra will interact with your system.

You will want to make sure that your detailed design can help you answer questions like:

What is the availability of your system, and is it fault-tolerant?
How is caching handled?
How are load balancers being used to distribute the load amongst servers?

You can prepare for this section by familiarizing yourself with the basic building blocks of system design.

Evaluation

At this stage, you will be evaluating your design against the functional and non-functional requirements.

Think: How effectively does your design meet those requirements, and what justifications do you have for the design you chose?

You will be expected to address any trade-offs you made during the design process, and how you weighed the benefits and drawbacks of different solutions. You will also want to spend some time identifying any aspects of your system design that could be improved upon. After all, there is no perfect solution to any problem, and improvements can always be made.

Distinctive component/feature

Every system design has unique components or features. That's why we included adding a distinctive component section to the RESHADED guideline.

Depending on what your needs are, you may need to include a unique feature to your system to meet the functional or non-functional requirements.

For example, if you're building a web application that will support multiple users at once, you might want to add some type of concurrency control mechanism to your design.

Why understanding modern system design will help you in your career

System design is a critical area of knowledge for any software engineer to master as they progress in their career.
Understanding the principles and components of modern system design can help you become a better developer, and can boost your earnings potential early on.

When you know how systems are designed, you can better understand the needs of a business, what features ought to be implemented, and the tradeoffs that need to be made to achieve this. With this high-level knowledge, you can make valuable contributions to design discussions, whether you're collaborating with others or in an interview setting.

This knowledge can also help you stand out in the job market, as employers are looking for developers who have a strong understanding of system design. Developers who can quickly understand the architecture, design, and goals of a system are well-poised to start making valuable contributions right away. Software engineers with a strong grasp of system design are generously compensated for their expertise, and command premium salaries.

The average base compensation for a senior software engineer as of 2022 is $146,110^[1]. Systems engineers are close behind with an average base salary of $121,966^[2].

Wrapping up and next steps

So, there you have it! The basics of the RESHADED guideline and how it can help you breeze through interviews, high-level software architecture discussions, and more. We encourage you to practice solving system design interview questions with RESHADED in mind to cement this guideline in your memory. We hope this article has given you a better understanding of what interviewers want to see in modern system design interviews and how you can prepare for them.

To get started learning these concepts and more, check out Educative's Grokking Modern System Design course.

Happy learning!

Continue learning about system design on Educative

Start a discussion

What other helpful strategies do you know for the System Design interview? Was this article helpful? Let us know in the comments below!

DEV Community