system design: a framework for approaching the problem

When presented with a question about system design, where do you begin?

The system-design-primer project on Github provides an accessible four-step approach:

1. Outline use cases, constraints, and assumptions
2. Create an initial high-level design
3. Design the core components
4. Scale the design

Outline Use Cases, Constraints, and Assumptions

What’s involved

Ask questions to clarify the problem, e.g., how would the system be used, who needs it, when do they need it, etc.

Outcome

By the end of this step, you should have stated your key understanding of the use case, its scope, and key assumptions / constraints, and implied usage.

Example

The following comes from a sample solution in the system design primer for Amazon Sales Rank By Category.

In terms of order of operations, the usage calculations require some sense of understanding what kind of data you’ll be storing.

How to estimate the storage requirements. Also, a handy conversion guide for quick estimates.

Problem statement:

• “Design Amazon’s sales rank by category feature”

Scope:

• Service will calculate the past week’s most popular products by category
• Users will be able to view the past week’s most popular products by category
• The service should be highly available

Out of scope:

• Designing the e-commerce aspects of the system which generate the sales Assumptions:

Assumptions and constraints:

• Traffic isn’t evenly distributed
• Items can be in multiple categories
• Items cannot change categories
• There are no subcategories
• Results must be updated hourly
• More popular products might need to be updated more frequently
• 10 million products
• 1000 categories
• 1 billion transactions per month
• 100 billion read requests per month
• 100:1 read to write ratio

Usage:

• Size per transaction:
  • created_at - 5 bytes
  • product_id - 8 bytes
  • category_id - 4 bytes
  • seller_id - 8 bytes
  • buyer_id - 8 bytes
  • quantity - 4 bytes
  • total_price - 5 bytes
  • Total: ~40 bytes
• 40 GB of new transaction content per month
• 40 bytes per transaction * 1 billion transactions per month
• 1.44 TB of new transaction content in 3 years
• Assume most are new transactions instead of updates to existing ones
• 400 transactions per second on average
• 40,000 read requests per second on average

Create an initial high-level design

This is where you actually draw out the core components of the system. Do not jump straight to a scaled design!

Design the core components

Identify which are the critical components

Design core APIs and processes

Scale the design

Identify single points of failure.

Outcome: A design diagram that scales the service to meet the usage requirements.