System Design Roadmap for Beginners
If you’re an absolute beginner in System Design, this roadmap will guide you step-by-step through all the key concepts using one consistent example: Instagram.
Each week includes the best YouTube videos to help you understand these concepts practically and visually!
If you like my work and find my resources useful, consider subscribing to this Newsletter to get them in your mailbox weekly :)
🗓️ Week 1 – Foundations
What is System Design?: The process of building software systems that can scale (handle millions of users), stay reliable (no crashes), and remain maintainable (easy to update and extend).
4 Core Components: Client, Server, Database, APIs.
Client: Your Instagram app on your phone.
Server: The machine that receives your request and processes it.
API: The contract that defines how your app talks to Instagram’s servers:
E.g.,GET /feedto fetch your timeline.Database: Stores everything: your account info, posts, reels, followers.
Types of APIs:
REST: The standard. Instagram uses REST to fetch posts, profiles, and comments.
GraphQL: Used by Facebook/Meta internally. Lets the client ask for exactly the fields it needs, reducing over-fetching. Google Maps also uses GraphQL for some APIs.
gRPC: Used for fast internal service-to-service communication.
Functional vs Non-Functional Requirements: Every system design starts by splitting requirements into two buckets.
Functional: What the system does.
Eg: For Instagram, we upload photos, view feed, like posts, share posts, etc.Non-Functional: How well it does it.
Eg: For Instagram, we load feed in under 200ms, handle 500M daily active users, 99.99% uptime.
Back-of-Envelope Estimation: Before designing anything, estimate scale.
Eg: Instagram has 500M DAU. If each user opens the app 5 times/day and each session fetches 20 posts, that is 50 billion feed reads per day, or ~580,000 reads per second. This tells you instantly that you need caching and a lot of horizontal scaling.Videos to Watch:
🗓️ Week 2 – Scaling Basics & Load Balancing
Vertical Scaling: Add more CPU/RAM to Instagram’s single server. Works early on, but there is a physical ceiling as you can only make one machine so powerful, and it creates a single point of failure.
Horizontal Scaling: Add more servers. Instagram runs thousands of servers in parallel to handle photo uploads, profile views, and feed requests simultaneously. This is how every major tech company scales.
Load Balancer: Routes incoming user requests evenly across all available servers so no single server is overwhelmed.
Round Robin: First request goes to Server 1, next to Server 2, and so on.
Least Connections: Routes to whichever server currently has the fewest active connections.
L4 vs L7:
L4 load balancers route by IP/TCP port (fast, dumb).
L7 load balancers route by URL path or HTTP headers (slower, smarter). Instagram uses L7 to route/feedrequests to Feed servers and/uploadrequests to Upload servers.
Stateless Services: Each request from your Instagram app like fetching feed, liking a post, posting a comment can be handled by any server because the server does not remember you between requests. Your authentication token travels with every request, so any server can verify who you are. This is what makes horizontal scaling work.
Health Checks & Failover: The load balancer continuously pings each server. If one goes down, it stops sending traffic to it automatically, so users never notice.
Videos to Watch:
🗓️ Week 3 – Databases & Data Partitioning
SQL vs NoSQL:
SQL (PostgreSQL/MySQL): Stores structured, relational data. Instagram uses SQL for user accounts, relationships (follow/unfollow), and post metadata. SQL gives you strong ACID guarantees: if you unfollow someone, that update is immediately consistent everywhere.
NoSQL (Cassandra, DynamoDB): Stores large volumes of flexible or semi-structured data. Instagram uses Cassandra for likes, comments, and activity feeds: operations where you need high write throughput and you can tolerate slight delays in consistency.
Replication: Instagram copies its database across multiple servers in different regions. If the US East database goes down, traffic automatically shifts to US West or Europe, and users don’t see an outage. One server is the primary (accepts writes), and others are replicas (serve reads).
Sharding (Partitioning): Splitting data across multiple databases so no single one becomes a bottleneck.
Hash-based sharding: User IDs are hashed and assigned to a shard. Instagram shards user data by user ID, your profile, posts, and followers live on the same shard for locality.
Range-based sharding: Users A–M → DB1, N–Z → DB2.
Hotspot problem: If Cristiano Ronaldo’s posts and Virat Kohli’s posts land on the same shard, that shard melts. Celebrity/viral content needs special handling (usually a dedicated shard or caching layer).
CAP Theorem: In a distributed system, you can only guarantee two of: Consistency, Availability, Partition Tolerance.
Instagram picks Availability + Partition Tolerance - when you hit “like,” the counter might show +1 a second late on someone else’s screen, but the app never goes down because of it.Indexes: Without an index, finding a user by email in a database of 1 billion rows means scanning every row (slow). An index is like a book’s index, it lets the database jump directly to the right row. Instagram indexes user IDs, post IDs, and hashtags so lookups are instant.
Videos to Watch:
🗓️ Week 4 – Caching & CDN
What is a Cache?: A fast, in-memory data store that saves the result of expensive database queries. When you open Instagram, your feed is served from a Redis cache and not from a database query, so it loads in milliseconds.
Cache Strategies:
Cache-aside (lazy loading): Check cache first. If not found (cache miss), query DB, store result in cache, return to user. Instagram uses this for user profiles.
Write-through: Every DB write also updates the cache simultaneously. Good for data that changes frequently and is read immediately after, like unread message counts.
Write-back: Writes go to cache first, DB is updated asynchronously. Fast writes, but risk of data loss if cache crashes before sync.
Cache Eviction Policies:
LRU (Least Recently Used): Evict the item not accessed for the longest time.
LFU (Least Frequently Used): Evict the item accessed the fewest times.
TTL (Time-to-Live): Every cached item has an expiry time. Instagram sets TTLs on feed caches so stale posts don’t show indefinitely.
Cache Invalidation: The hardest problem in caching. When a user deletes an Instagram post, you need to update or invalidate all cached feeds that contain that post across thousands of servers, instantly.
CDN (Content Delivery Network): A globally distributed network of edge servers that stores static content (images, videos, profile pictures) close to users.
When you post a photo on Instagram, it is uploaded to an origin server (e.g., AWS S3 in Virginia), then distributed to CDN nodes in India, UK, Brazil, etc. When someone in Mumbai views it, it loads from the Mumbai CDN node, not from Virginia. This is why Instagram loads fast worldwide.
Latency vs Throughput: Caching and CDN both reduce latency (the time for a single request to complete) and increase throughput (the total number of requests handled per second).
Videos to Watch:
🗓️ Week 5 – Distributed Systems Building Blocks
These are the “power tools” of system design. Interviewers expect you to know each one cold.
Consistent Hashing: A technique for distributing data across servers so adding or removing a server doesn’t require reshuffling all data.
Normal hashing: If you have 3 cache servers and hash user IDs mod 3, adding a 4th server invalidates ~75% of your cache. That is catastrophic.
Consistent hashing: Place servers and data keys on a ring. Each key is served by the nearest server going clockwise. Adding a server only moves ~25% of keys.
Instagram uses consistent hashing to distribute users across cache nodes so that when a cache server is added, only a fraction of users are rerouted.
Rate Limiting: Controls how many requests a client can make in a given time window, preventing abuse and protecting services.
Token Bucket: Each user has a bucket that refills at a fixed rate (e.g., 10 tokens/second). Each request costs 1 token. When the bucket is empty, requests are rejected.
Sliding Window: Tracks request count over a rolling time window. More accurate than fixed windows.
Blob / Object Storage: For storing large files: photos, videos, audio, you don’t use a relational database. You use object storage (Amazon S3, Google Cloud Storage).
When you upload a Reel on Instagram, the video file goes to object storage. The database only stores metadata (video ID, timestamp, uploader) and a URL pointing to the object store. Object storage is infinitely scalable, cheap, and durable.
Videos to Watch:
🗓️ Week 6 – Event-Driven Architecture
Message Queues: Decouple services and handle background jobs asynchronously.
When you upload a photo on Instagram, the app immediately shows a preview. But processing (compressing to different resolutions, extracting thumbnails, running content moderation ML models) happens asynchronously via a message queue like Kafka or RabbitMQ. The upload service puts a “photo uploaded” event in the queue and returns instantly. Worker services pick up the job and process it in the background.
Kafka vs RabbitMQ:
RabbitMQ / SQS (Message Queue): Messages are consumed once and deleted. Good for task queues, e.g., “send this push notification.”
Kafka (Event Log): Messages are retained and replayable. Multiple services can independently consume the same event. Instagram uses Kafka so the Feed Service, Notification Service, and Search Index all consume the same “photo uploaded” event independently.
Publish–Subscribe (Pub/Sub): One event triggers updates across multiple services simultaneously.
When you post on Instagram: the Feed Service fans out your post to your followers’ feeds, the Notification Service sends push notifications to them, and the Search Index adds your post so it appears in Explore. All three happen in parallel from a single “photo uploaded” Kafka event.
Dead Letter Queue (DLQ): If a worker fails to process a message after several retries, the message is moved to a DLQ for inspection. This prevents one bad message from blocking the entire queue.
Videos to Watch:
🗓️ Week 7 – Networking, APIs & Microservices
Protocols:
HTTP/HTTPS: Instagram uses HTTPS for all client-server communication.
WebSockets: A persistent two-way connection. Instagram Direct Messages use WebSockets so new messages appear instantly without the app polling the server every second.
REST API Design:
Use HTTP status codes correctly: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 429 Too Many Requests, 500 Internal Server Error.
Pagination: Never return all 500 posts at once.
Idempotency: A double-tap on Instagram should only create one like. The API uses idempotency keys to ensure retried requests don’t create duplicate records.
Monolith vs Microservices:
Monolith: Instagram started as a monolith, all logic (login, posting, comments, notifications) lived in one Ruby on Rails codebase. It deployed fast at first, but as the team grew, deployments became risky and one bug could crash everything.
Microservices: Instagram now runs independent services - User Service, Post Service, Feed Service, Notification Service, Search Service, each with its own codebase, deployment pipeline, and database. A bug in the Notification Service does not bring down photo uploads.
API Gateway: A single entry point that receives all client requests and routes them to the correct microservice. It also handles authentication, rate limiting, logging, and request transformation, so each microservice doesn’t have to implement these separately.
Videos to Watch:
🗓️ Week 8 – Security & Authentication
Authentication vs Authorisation:
Authentication: Proving who you are. When you log into Instagram, you prove through your username and password.
Authorisation: What you’re allowed to do. Once logged in, you can only edit your posts, not someone else’s.
Sessions vs Tokens:
Session-based auth: After login, the server stores your session in a database and gives you a session ID cookie. On every request, the server looks up the session ID. Does not scale well across thousands of servers.
JWT (JSON Web Token): After login, the server issues you a signed token containing your user ID and permissions. You send this token with every request. Any server can verify it by checking the signature, no shared database needed.
HTTPS / TLS: All data between your phone and Instagram’s servers is encrypted. Without this, anyone on the same Wi-Fi network could read your messages or intercept your password.
Password Hashing: Instagram never stores your plain-text password. It runs it through a slow hashing function (bcrypt or Argon2) and stores only the hash. Even if Instagram’s database were stolen, your password couldn’t be recovered.
CORS (Cross-Origin Resource Sharing): Prevents malicious websites from making API calls to Instagram on your behalf. Instagram’s API only accepts requests from approved origins (its own app and website).
Video to Watch:
🗓️ Week 9 – High-Level Design
Practice these end-to-end. For each, you should be able to talk for 45 minutes covering: requirements, estimation, high-level design, component deep dives, and trade-offs.
How to Approach Every HLD Problem:
Clarify functional requirements (what it does) and non-functional requirements (scale, latency, availability, consistency).
Estimate scale: QPS (queries per second), storage, bandwidth.
Draw the high-level architecture: client → API gateway → services → databases.
Deep dive on 2–3 critical components the interviewer picks.
Discuss trade-offs: Why this approach over alternatives.
Videos to Watch:
🗓️ Week 10 – Low-Level Design
Understand Design Patterns:
Creational:
Singleton (one shared instance),
Factory (create objects without specifying exact class,
Builder (construct complex objects step by step,
Prototype (clone existing objects).Structural:
Adapter (make incompatible interfaces work together),
Decorator (add behaviour dynamically),
Proxy (an intermediary),
Facade (simplify a complex subsystem),
Composite (tree structures).Behavioral:
Observer (notify dependents of state changes),
Strategy (swap algorithms at runtime),
Command (encapsulate actions as objects),
State (an object behaves differently based on state),
Chain of Responsibility (pass request along a chain of handlers).
SOLID Principles: The five principles behind maintainable code.
S – Single Responsibility
O – Open/Closed
L – Liskov Substitution
I – Interface Segregation
D – Dependency Inversion
UML Diagrams: Practice drawing Class diagrams (structure), Sequence diagrams (interaction over time), and Component diagrams (system architecture).
Videos to Watch:
🗓️ Week 11 – Interview Prep
Use ChatGPT For Predicting Interview Questions: PROMPT
Most Frequently Asked System Design Questions: HERE
System Design Full Course (A-Z) and Common Interview Questions | Mock Interview (Scaler)
System Design Mock Interview: Design LeetCode ft. Ex-Google Engineer (Anubhav Sethi)
System Design Mock Interview: Design TikTok ft. Google TPM (Exponent)
Final Thoughts
System design is a skill you build through exposure and practice, not memorisation. Focus on understanding why each component exists and once you do, you can reason about any new system from first principles.
If you want more resources on tech, AI, productivity and interview prep, follow me on:
Instagram (295K+ followers)
LinkedIn (40K+ followers)
I hope this helps you :)
Great info
Great info