The RESHADED Approach for System Design

Introduction

System design problems are inherently open-ended and lack a single correct solution. A structured approach helps organize requirements, constraints, and trade-offs. This framework is referred to as the RESHADED approach. Although no framework guarantees optimal design, this guideline provides a consistent, systematic way to evaluate different system design problems.

Advantages of RESHADED

Key advantages of this approach include:

1. Guidance: It provides a clear roadmap, ensuring the next step is always visible.

2. Completeness: It ensures the solution is systematic and includes all essential ingredients.

Exploring RESHADED

The steps of the RESHADED framework are described below:

Requirements: During this step, we gather all the requirements of the design problem and define its scope. Requirements include understanding what the service is, how it works, and its main features. Our goal in this step is to gather the functional and non-functional requirements of a service we are about to design.

Estimation: As the name suggests, this step estimates the resources required to provide the service to a defined number of users. By resources, we mean the hardware or infrastructural resources.

Sample estimation questions include:

1. How many servers are needed to support 500 million daily active users (DAU)?

2. How much storage is required for 125 million tweets per day, assuming 20% contain media?

Estimations clarify the system’s scale and drive key decisions, such as database selection and data structure optimization.

Storage schema (optional): This step involves articulating our data model, that is, we define which tables we need and what type of fields are part of each table. However, this is an optional step, and we may not put in this effort for every design problem.

High-level design: This step involves identifying the main components and building blocks we’ll use to design our desired system. We do this by getting inspiration from our functional and non-functional requirements.

This serves as the initial architectural draft and is subject to iteration.

API design: The goal in this phase is to build interfaces for our service. Using these interfaces, users can call various services within our system. These interfaces are implemented as API calls and generally translate our functional requirements.

Detailed design: The detailed design starts by recognizing the limitations of the high-level design. We’ll capitalize on these limitations to evolve our design. During this step, we’ll finalize our design by mentioning all the components and building blocks that we’ll use.

Evaluation: This step will measure the effectiveness of our solution. In other words, we justify how our design fulfills the functional and non-functional requirements.

Distinctive component/feature: Identify and discuss unique challenges specific to the problem. For example, fraud detection in Uber or concurrency control in Google Docs.

Next, we will apply the RESHADED framework to various design problems.