System Design Module 2: The Interview Framework (PEDAL)

Why use a Framework?

The biggest reason candidates fail system design interviews is lack of structure. Without a framework, you miss critical requirements and run out of time before reaching the most important components.

1. The PEDAL Framework

graph LR
    P[Parameters] --> E[Estimates]
    E --> D[Diagrams]
    D --> A[APIs & Data]
    A --> L[Logic / Deep Dive]

Parameters (Clarify Requirements) - 5 mins

Ask questions to narrow the scope.

Functional: "Can users post comments? Can they delete them?"
Non-Functional: "What is the expected latency? 99.99% availability?"

Estimates (Capacity Planning) - 5 mins

Traffic: RPS (Requests Per Second).
Storage: Total data over 5 years.
Memory: How much cache do we need?

Diagrams (High-Level Design) - 10 mins

Draw the "box and arrow" diagram.

Load Balancer $\rightarrow$ API Gateway $\rightarrow$ Microservices $\rightarrow$ DB.

APIs & Data (Contracts & Schema) - 5 mins

API: POST /v1/tweet { text: string }.
DB: Table names, Partition keys, and Indexes.

Logic (The Deep Dive) - 20 mins

This is where you show Staff-level expertise:

"How do we scale this for 1 billion users?"
"What happens during a regional outage?"

2. Time Management Guide (45-Minute Session)

gantt
    title System Design Interview Timeline
    dateFormat  mm
    axisFormat  %M
    section Phases
    Clarify (P)      :00, 5m
    Estimate (E)     :05, 5m
    High-Level (D)   :10, 10m
    API/Data (A)     :20, 5m
    Deep Dive (L)    :25, 20m

3. The "Senior" Secret: Thinking Aloud

Don't just draw in silence. Every box you place should be accompanied by a trade-off:

"I am choosing Cassandra over MySQL here because we need high-volume ingestion and don't require ACID across multiple tables."
"I'll add a Redis cache here to offload the 90% read traffic from the primary DB."