Database Design

AI Take..

System Design Pathway: From 0 to "Can design Twitter/YouTube"

Think of it like building a house. You don't start laying bricks. You start with: "How many people live here?"

Here’s the full step-by-step framework FAANG + startups use:

THE 6-STEP SYSTEM DESIGN FRAMEWORK

STEP 1: REQUIREMENTS CLARIFICATION - "What are we building?"

Goal: Don't build the wrong thing

1. Functional Requirements: What must the system DO?
   Bad: "Build YouTube"
Good: "Users can upload, watch, search, comment, like videos"
2. Non-Functional Requirements: How well must it work?
   Scale: 1M DAU? 1B DAU?
Latency: <200ms?
Consistency: Can comments be 2s delayed?
3. Out of Scope: What are we NOT building?
   V1: No live streaming. No 4K.

Rule: Spend 5-10 min here. Ask tons of questions.

STEP 2: HIGH LEVEL DESIGN / BACK OF ENVELOPE - "Big boxes"

Goal: Draw the main components
[Users] -> [Load Balancer] -> [API Servers] -> [App Logic]
-> [Cache: Redis]
-> [Database: Postgres]
-> [Object Storage: S3 for videos]
-> [CDN: Cloudflare]
-> [Queue: Kafka for processing]
Ask: Stateless? Where is data stored? What talks to what?

STEP 3: DATABASE DESIGN - "How do we store data?"

This is what you asked about 👇

1. Entities: User, Video, Comment, Like
2. Tables + Schema:
   users(id, name, created_at)
   videos(id, user_id, url, views)
   comments(id, video_id, user_id, text)
3. Relationships: 1 User - Many Videos
4. Scale: 1B videos? Partition by video_id. Add read replicas.
5. Indexes: Index videos.user_id for "get my uploads"

STEP 4: DETAILED COMPONENT DESIGN - "Zoom into 1 box"

Pick the hardest part and design it deep.
Examples:

1. News Feed: How to generate feed? Pull vs Push model?
2. Upload: How to handle 4GB video? Chunk upload + async encoding
3. Search: ElasticSearch vs DB LIKE query?
4. Rate Limiting: Token bucket in Redis

Draw sequence diagrams. User -> API -> Cache miss -> DB -> Cache set -> Return

STEP 5: SCALE + BOTTLENECKS - "What breaks at 10M users?"

Go through each component and ask "What fails first?"

1. DB: Too many writes → Sharding, Replication
2. API: Too many requests → Auto-scaling, More servers
3. Storage: Too expensive → CDN, Compression
4. Single Point of Failure: 1 DB → Master-Slave, Multi-region

STEP 6: JUSTIFY + TRADEOFFS - "Why not Kafka?"

The interviewer will poke holes.
Q: "Why SQL and not Mongo?"
A: "We need transactions for payments. Mongo is eventually consistent"

YOUR LEARNING PATHWAY: 8 WEEKS TO GET GOOD

Week | Focus | Practice
1-2 | Fundamentals | Learn: Load Balancer, Cache, DB, CDN, Queue, CAP Theorem. Build 1 tiny system
3-4 | Database + Scaling | Normalization, Indexing, Sharding, Replication. Design: Instagram DB
5-6 | Core Patterns | Practice 10 classic systems: URL Shortener, Rate Limiter, Chat, Feed, YT, Uber
7 | Advanced | Consistent Hashing, Distributed Transactions, Microservices vs Monolith
8 | Mock Interviews | Time yourself: 45min per design. Explain out loud

3 RULES THAT WILL SAVE YOU

1. Always start with scale: "How many users?" changes everything. 1k users = 1 server. 1B users = 1000 servers
2. Draw first, talk second: 1 diagram > 1000 words. Use boxes + arrows
3. Say your tradeoffs: "Redis is fast but we lose data on crash. So we also write to DB"

Free resources to start today

1. Book: "System Design Interview Vol 1 & 2" by Alex Xu
2. YouTube: Gaurav Sen, NeetCode System Design
3. Practice: systemdesign.one - has diagrams for all big tech systems

Want me to run you through a full example using this 6-step framework?

Pick 1:

1. URL Shortener like http://bit.ly - Easiest to start
2. eFootball Stats Tracker - Based on your other questions
3. SaaS App for your startup - Most relevant to you

Which one should we design together step by step?