I’m excited to announce the launch of a brand new online course: the System Design Interview. It’s hosted on our Teachable platform.

I’ve noticed that system design (SD) questions become remarkable popular across a range of different roles from software engineering to product management. I’ve also found that system design questions have been common with both experienced and entry-level roles.

However, in my review of current interview prep materials for SD questions, I’ve found that most materials aren’t as helpful or comprehensive as advertised. One of the biggest problems is the lack of a clear-cut, definitive framework to help candidates navigate their way through an SD question. And hence, my co-author, Shivam P. Patel, and I devised a new framework called PEDALS™.

What is the PEDALS Method™?

PEDALS™ is a framework for answering system design interview questions.

You can think of it as a checklist: it reminds us what components to discuss to make sure we have a complete and thoughtful answer. It prevents us from forgetting critical steps.

PEDALS stands for:

Process Requirements
Estimate
Design the Service
Articulate the Data Model
List the Architectural Components
Scale

I’ll summarize each one of the components below.

What are system design questions?

System design questions test one’s ability to build software systems from scratch. Here are some examples:

Design an API for a payment provider.
Design an order inventory system.
Design a question and answer website like Quora.
Create a back-end system that created unique IDs.

What are interviewers looking for?

Software engineers and architects are most likely to get system design (SD) questions. However, the following folks get SD questions too:

Product Managers
Technical Program Managers
QA Testers
Data Scientists
Data Engineers
Support Engineers

SD questions appear at the interview because the roles above play a big part in building software systems that scale. Unlike the pre-Internet era, a modern application must work across thousands of servers, ready to serve millions and perhaps billions of users.

Interviewers love SD questions because it tests a candidate’s ability to:

Specify system requirements clearly
Articulate the desired system behavior
Specify constraints
Contribute to technical brainstorming
Point out technical drawbacks
Decide between technical tradeoffs

As a result, during the SD question, the interviewer wants you to specify:

The key services, preferably in RESTful API format
Define the data model
Define the cloud architecture, with an emphasis on scale

How to approach system design questions with pedals

Process requirements

What we really mean when we say process requirements is “clarify” the question:

What features does the service include?
How does it work?

Going further:

What are the goals or outcomes?
What are the constraints?
What features should be left out?

Many candidates forget to clarify the requirements. They jump in, finding they forgot an important goal. Other times, they fail to scope the problem, allowing their response to run too long, covering minutiae that the interviewer doesn’t care about. Both mistakes can result in rejection.

Estimate

This is an optional step, but sometimes interviewers want candidates to estimate, as part of processing the requirements:

Servers needed
Storage needed
Anticipated requests per second

If you’re familiar with Fermi or market sizing questions, doing a quick back-of-the-envelope estimate shouldn’t intimidate you.

Design the service

This is about fleshing out key components of the service. For example, to build an online video service, you might consider services that:

Videos: allow users to view, upload, or delete
Users: allow for creation, viewing, modification, or deletion
Etc.

Articulate the data model

This is about defining the database tables and the corresponding fields. If you defined the API well, then each service endpoint should be a corresponding DB table.

For example, with an online video service, there should be a videos and users table, among others.

From there, interviewers want you to specify the fields inside each table. For example, with the user table, some potential fields can include:

username
first_name
last_name
email
user_id
create_date
modify_date

List the Architectural Components

Listing the architectural components is about cloud architecture diagrams. That is, what cloud services do you need to enable your service? Do you need a server like Amazon’s EC2? Or simple file storage like Amazon’s S3?

If you’re not comfortable drawing cloud architecture diagrams, do take a moment to practice.

[caption id="" align=“alignnone” width=“974”] Screenshot: Rightscale + Simform [/caption]

Scale

Scale is about adding to your basic cloud architecture so that it can handle more than a handful of users. Some cloud components you may consider adding include:

Horizontal or vertical scaling
Load balancing
Read replica databases
Content delivery networks
Daemon process pre-computation

Intro the PEDALS Method™ Framework for System Design