System Design Round — Complete Interview Framework and Problem Solving

In this tutorial, you'll learn about System Design Round. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

The system design interview evaluates your ability to architect large-scale Distributed Systems, make tradeoff decisions under ambiguity, and communicate complex technical concepts clearly. A structured 45-minute framework separates strong candidates from weak ones.

What You'll Learn

You'll master a repeatable 5-step framework for any system design problem, learn back-of-envelope estimation for capacity planning, practice data model and API design, identify deep dive areas that impress interviewers, and analyze tradeoffs between consistency, availability, and partition tolerance.

Why It Matters

System design interviews at companies like Google, Meta, Amazon, and Netflix determine engineering level and compensation. Senior engineers are expected to design systems that handle millions of users, and staff engineers must justify every architectural decision with quantitative reasoning. At DodaTech, the system design principles covered here directly apply to the distributed architecture of Durga Antivirus Pro's real-time threat detection grid.

Real-World Use

An interviewer asks "Design YouTube." In 45 minutes, you must scope the problem to video upload and streaming, estimate storage requirements for 500 hours uploaded per minute, design the video encoding pipeline, plan the CDN strategy, and discuss how you would handle a viral video that generates 10 million views in an hour.

The 5-Step Framework

flowchart LR
    A[1. Requirements
5 min] --> B[2. Estimation
5 min]
    B --> C[3. Data Model + API
10 min]
    C --> D[4. High-Level Design
10 min]
    D --> E[5. Deep Dive
10 min]
    E --> F[6. Tradeoffs + Wrap
5 min]

Step 1: Requirements Gathering

Clarify functional and non-functional requirements before writing any code.

Back-of-Envelope Estimation

def estimate_capacity(dau: int, daily_actions: int, action_size_bytes: int):
    total_actions = dau * daily_actions
    storage_per_day = total_actions * action_size_bytes
    qps = total_actions / (24 * 3600)

    print(f"Daily actions: {total_actions:,}")
    print(f"Storage/day: {storage_per_day / 1024**3:.1f} GB")
    print(f"Storage/year: {storage_per_day * 365 / 1024**3 / 1024:.1f} PB")
    print(f"Average QPS: {qps:,.0f}")
    print(f"Peak QPS (2x): {qps * 2:,.0f}")

# Example: Design YouTube
# 100M DAU, each watches 5 videos, each video 200MB
estimate_capacity(dau=100_000_000, daily_actions=5, action_size_bytes=200 * 1024 * 1024)

Expected behavior:

Daily actions: 500,000,000
Storage/day: 93.1 GB
Storage/year: 33.2 PB
Average QPS: 5,787
Peak QPS (2x): 11,574

Use these numbers to justify your storage choices (object storage), caching strategy (CDN), and database selection (NoSQL for high write throughput).

Data Model Design

Define the core entities and their relationships clearly.

-- Video service core data model
CREATE TABLE users (
    user_id UUID PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE videos (
    video_id UUID PRIMARY KEY,
    user_id UUID NOT NULL REFERENCES users(user_id),
    title VARCHAR(200) NOT NULL,
    description TEXT,
    duration_seconds INT NOT NULL,
    storage_path TEXT NOT NULL,
    thumbnail_url TEXT,
    status VARCHAR(20) DEFAULT 'processing',
    upload_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_user_upload (user_id, upload_time DESC)
);

CREATE TABLE video_views (
    video_id UUID NOT NULL,
    viewed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    viewer_id UUID,
    watch_seconds INT,
    INDEX idx_video_time (video_id, viewed_at)
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(viewed_at)
ORDER BY (video_id, viewed_at);

CREATE VIEW daily_video_stats AS
SELECT
    video_id,
    toDate(viewed_at) AS day,
    count(*) AS views,
    uniq(viewer_id) AS unique_viewers,
    avg(watch_seconds) AS avg_watch_time
FROM video_views
GROUP BY video_id, day;

API Design

Deep Dive Areas

Choose 1-2 areas to dive deep based on interviewer interest:

Common Errors

1. Jumping to Design Without Requirements

Starting with "we'll use Kafka" without understanding the problem leads to wrong architectures. Spend the first 5 minutes clarifying requirements and constraints.

2. Ignoring Scale

Designing a system that works for 1000 users but not 100 million. Always mention how your design scales. "This approach works for 10K QPS. Beyond that, we would introduce a message queue and batch processing."

3. Single Point of Failure

Designing without redundancy. Every component needs a backup. "The load balancer is active-active. Each service has at least 2 replicas across availability zones."

4. No Numbers

Just saying "we need a cache" without specifying cache size, eviction policy, or hit ratio targets shows shallow thinking. "We need a Redis cache with 500GB capacity, LRU eviction, and 95 percent target hit ratio."

5. Over-Engineering

Adding Kafka, Kubernetes, 15 microservices for a system with 10K users. Start simple and explain when and why you would add complexity.

6. Ignoring Tradeoffs

Every design choice has tradeoffs. Acknowledge them. "I'm choosing eventual consistency here to prioritize availability. If the business requires strong consistency for payments, I would use a different approach."

7. Poor Time Management

Spending 30 minutes on requirements leaves no time for design. Use a timer mentally. At 5 minutes, move to estimation. At 15 minutes, start the design. At 35 minutes, begin wrapping up.

Practice Questions

1. What is the most important skill in a system design interview?

Asking clarifying questions. Most problems are deliberately ambiguous. The best candidates scope the problem to match the 45-minute window and identify the most critical components to design in depth.

2. How do you choose between SQL and NoSQL for a system?

SQL for strong consistency, complex queries, and well-defined schemas. NoSQL for high write throughput, flexible schemas, and horizontal scaling. In practice, most systems use both — SQL for transactional data, NoSQL for high-volume event data.

3. What should you do if you do not know a technology the interviewer asks about?

Be honest but show your thought process. "I have not used Kafka directly, but I understand pub-sub patterns. I would design a message queue with these characteristics: persistent, ordered, partitioned, and replayable. Kafka would be a strong candidate for implementation."

4. How do you handle the interviewer disagreeing with your design?

Listen to their concern, consider their perspective, and explain your reasoning. "You raise a good point about shard rebalancing. I chose consistent hashing to minimize data movement. If rebalancing frequency is a concern, we could also use a two-level mapping with a lookup table."

5. Challenge: Design a real-time collaborative document editing system like Google Docs. Focus on the Conflict Resolution mechanism. Compare OT (Operational Transformation) and CRDT (Conflict-Free Replicated Data Types) approaches. Explain how you would handle offline editing and reconnection.

Mini Project: System Design Practice Framework

Build a system design practice tool:

1. List 20 common system design problems (URL shortener, chat, Uber, Instagram, Netflix, etc.)
2. For each problem, write a checklist covering requirements, estimation, data model, API, design, and tradeoffs
3. Practice with a timer — 45 minutes per problem
4. Record your solutions and evaluate against the checklist
5. Focus on the 2-3 problems you found most challenging and redo them until they flow naturally

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.