Simplify system design interviews with the RESHADED approach

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.

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?

• 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?

• 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

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.

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.

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.

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.

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.