Getting to the Finish Line with RESHADED
Learn an 8-step method for structuring your design process.
We’ll cover the following
The RESHADED method
To take your solution to the finish line, use the RESHADED approach to solve design problems.
As illustrated below, RESHADED is an 8-step method consisting of the following steps:
Let’s review the steps of RESHADED. We’ll provide some examples of how these steps would be applied to a commonly known System Design problem—designing TinyURL.
Requirements
In this step you compile a complete image of the system’s functional and non-functional requirements. You can create a matrix of these requirements on the whiteboard.
To clarify requirements, ask your interviewer about the system’s constraints and what needs to be considered. Don’t make too many assumptions; be honest about anything you don’t know.
For instance, you could ask the interviewer some questions such as:
- “What are the average daily active users (DAU) for the system?”
- “Are there any hardware constraints that I should know about?”
For example, TinyURL’s requirements would include the following:
- Short URL generation—Generate a unique shorter alias of a given URL.
- Redirection—Redirect the user from the short URL to the original URL.
Estimation
In this step, your goal is to estimate the hardware and infrastructure required to complete the core action at the desired scale. Your estimate might include things like data storage, the number of servers needed, and network requirements.
For TinyURL, we would determine the amount of bandwidth, storage, and servers we need to handle our requests.
Storage schema (optional)
This is where you’ll define the structure of your data. This is especially vital for systems that require multiple types of data to be stored/produced. Though this step is optional, it is usually helpful for the planning process to determine how to handle your data effectively. Depending on the expertise required for your role, your interviewers may ask you relevant storage questions to test your knowledge.
High-Level design
This is where you’ll confirm which of the building blocks of System Design you’ll need to complete the previously defined functional requirements of the system. Apart from employing some (or all) of your building blocks, you will need to use components unique to your design problem, as you will see shortly.
For TinyURL, our building blocks would include some of the common SLIC FAST components we discussed:
A Database (storage) to store the mapping of original URLs and corresponding short URLs.
Load balancers to ensure smooth requests distribution among available servers.
Caches to store the most frequent short URLs related requests.
Front-end servers to handle and navigate service requests.
Outside of the common 8, TinyURL requires a couple other components to fit its unique needs:
Rate limiters to prevent system exploitation.
A Base-58 encoder to change the sequencer’s output into a more readable alphanumeric form.
Application Programming Interfaces (APIs)
APIs enable clients (internal or external) to access different services of our system through endpoints. In this step you map the functional requirements of our system to the various endpoints of our API. Thus, APIs can be considered the intermediary between back-end services and the clients requesting those services.
For instance, with TinyURL, we would use REST APIs to:
Shorten URLs
Redirect short URLs
Delete short URLs
Detailed design
This step is where the non-functional requirements you gathered earlier will come into play. By implementing components that meet the non-functional requirements, you are polishing your final design. This step should produce a fully realized outline of which components and technologies will be used.
On the whiteboard, your design for TinyURL might look like this:
Evaluation
Now it’s time to compare your design to the non-functional and functional requirements of the system. You will be expected to acknowledge any trade-offs you made during the process and how you weighed the strengths and weaknesses of various solutions. This phase is also useful to further polish certain aspects of the design. For example, you can improve your solution’s reliability by considering disaster recovery and adding regional failover features to the final design.
Distinctive component/feature
Each system you’ll be asked to design has unique components and/or features. Depending on what your system’s needs are, you may need to add a unique feature to your system to meet the distinctive functional or non-functional requirements.
This step can be done at any point in the design process and does not have to come last. For TinyURL, a distinctive component could be the Base-58 encoder.
Note: To see the full walkthrough of designing TinyURL and 12 other real-world design problems, check out Grokking Modern System Design for Engineers & Managers.
