You Already Know System Design. You Just Do Not Know It Yet.
Open your phone. Tap Instagram. In under a second, your home feed loads photos and videos from hundreds of accounts, sorted by an algorithm that somehow knows what you care about. You double tap to like a photo. One millisecond later the heart animates. The person who posted it gets a push notification across the world. Meanwhile, 2 billion other people are doing the exact same thing at the exact same moment. Nothing crashes. Nobody waits. That seamless experience is not magic. It is the result of deliberate, careful, repeatable planning. That planning is what we call system design for beginners need to understand first.
If you have ever decided to put the fridge near the kitchen door so groceries are easy to unload, or arranged your desk so your monitor, keyboard, and coffee mug are exactly where your hands naturally fall you have already practiced design thinking. System design is that same instinct applied to software: figuring out where things should live, how they connect, and what happens when something goes wrong. The difference is scale. Your desk serves one person. Instagram serves two billion.
What Exactly Is System Design?
System design is the process of defining the architecture, components, data flow, and interfaces of a software system so that it meets its requirements reliably under real world conditions. That sentence has a lot of jargon, so let us break every word down.
Architecture: The structure of the entire system - which major pieces exist and how they relate to each other. Like a building's floor plan before any bricks are laid.
Components: Individual building blocks - a database, a server, a cache, a message queue. Each component has a specific job.
Data flow: The path a user's request takes from the moment they tap a button to the moment they see a response. Which component touches the data first? Where does it go next?
Interfaces: The contracts between components. When Service A talks to Service B, what exactly does it send, and what does it expect back?
Requirements: What the system must do (features) and how well it must do it (performance, reliability, cost). A chat app that delivers messages in 5 minutes is technically working but practically useless.
In plain English: system design is deciding how to build something before you build it, so that it works well, stays fast, does not lose data, and can grow when more people start using it.
The City Analogy - Understanding Systems Through Urban Planning
This analogy is the single most useful mental model for understanding system design. We will come back to it throughout this entire guide.
Imagine you are the mayor of a brand-new city. Currently it is empty land. 50,000 people are moving in next month, and 5 million more will arrive over the next five years. You need to plan everything before the first resident arrives.
Roads and Highways = Network and Load Balancers
You need roads so people can move around. A single two-lane road works for 50 people. But when the population hits 500,000, that same road becomes a parking lot. You need highways (high-bandwidth network connections), interchanges (load balancers that route traffic efficiently), and traffic signals (rate limiters that prevent any one road from getting overwhelmed). In software, when millions of users send requests simultaneously, you need the digital equivalent of highways and traffic management.
Power Plants = Servers and Compute
Every building needs electricity. You do not give each house its own generator - that would be absurdly expensive and impossible to maintain. Instead, you build a few large power plants (servers) and connect them to the grid (network). If one plant goes down for maintenance, the others cover the load. That is redundancy. In software, you run multiple copies of each server so that if one crashes at 3 AM, the others keep serving users without anyone noticing.
Warehouses = Databases
Where does the city store its records? Birth certificates, property deeds, tax records - they go in a secure warehouse (database) with filing systems (indexes) so any record can be found quickly. The warehouse has backup copies in a separate building (replicas) in case of fire. Some warehouses are strict and organized (SQL databases - every record follows the same format). Others are flexible (NoSQL databases - each record can have a different shape). Both have their place.
Bulletin Boards = Caches
The city's most-requested information - bus schedules, emergency contacts, upcoming events - gets posted on bulletin boards at every major intersection. Instead of every person visiting city hall to ask the same question (hitting the database), they read the bulletin board (cache). The bulletin board is updated every few hours. It is not always perfectly current, but it is fast and saves city hall from being overwhelmed. In software, this is exactly what Redis or Memcached does - stores frequently-accessed data in memory for instant retrieval.
Postal Service = API Design
How does one city department communicate with another? Through a postal service with strict rules: standard envelope sizes, required return addresses, specific mailbox locations, delivery tracking. If the Fire Department needs data from the Water Department, it does not wander into their building. It sends a formal request through the post. That is an API (Application Programming Interface) - the standardized communication contract between services.
Building Blueprints = Low-Level Design (LLD)
Once you have decided that the city needs a hospital at coordinates X, Y (HLD decision), an architect designs the internal layout: where the operating rooms go, how the plumbing works, where the electrical panels sit, which walls are load-bearing. That internal blueprint is LLD. In software, LLD means designing the database tables, their columns, data types, relationships, indexes, and constraints inside each component.
HLD is the city master plan. LLD is the blueprint for each building. API Design is the postal system connecting them. Learn all three and you can design any system.
Why System Design Matters More Than You Think
Reason 1: It Is the Single Highest-Leverage Interview Skill
At companies like Google, Amazon, Meta, Microsoft, Netflix, Stripe, and hundreds of well-funded startups, the system design interview round is often the round that determines your level and compensation. A candidate who aces coding but stumbles on system design gets hired at a lower level (and lower salary) than a candidate who shows strong design thinking. The difference can be $50,000-$150,000 per year in total compensation. This is not an exaggeration. At senior levels, system design performance is literally the deciding factor.
Reason 2: Coding Alone Cannot Build Products
A computer science degree teaches you to write functions, algorithms, and data structures. That is necessary. But it does not teach you how to go from 'I can write a function that sorts a list' to 'I can build a ride-sharing app that handles 14 million trips per day across 60 countries'. The gap between coding and building products is system design. It is the skill that transforms a developer (someone who writes code) into an engineer (someone who designs systems that actually work in production).
Reason 3: Bad Design Costs Real Money
In 2017, a single misconfigured server at Amazon S3 caused a four-hour outage that took down Netflix, Slack, Quora, and thousands of other websites. Amazon lost an estimated $150 million in revenue during those four hours. The root cause was not a coding bug. It was a design flaw: a single point of failure in a critical system. Good system design prevents these catastrophes. Bad system design causes them. When you understand design, you become the person who catches the flaw before it reaches production.
Reason 4: It Gives You a Common Language
Have you ever been in a meeting where architects say things like 'We should add a Redis layer in front of the read replicas and use Kafka for the async fan-out' and you just nod along? System design gives you that vocabulary. Once you understand what each component does and why, you stop being the person nodding and start being the person contributing ideas, spotting flaws, and proposing solutions. That visibility is how engineers advance from mid-level to senior to staff.
Reason 5: Every System You Use Was Designed
Google Search returns results in 0.3 seconds after searching through billions of web pages. WhatsApp delivers 100 billion messages per day across 180 countries. Spotify streams 100 million songs with near-zero buffering. Netflix serves 247 million subscribers with 99.99% uptime. None of this happened by accident. Every one of these systems was deliberately designed by engineers who understood the principles you are about to learn.
The Three Pillars of System Design
Every software system, from a simple todo app to Instagram, is designed across three layers. These layers have official names that come up in every interview, every architecture review, and every engineering discussion. The three pillars are as follows:
Pillar 1: HLD - High-Level Design (The Bird's Eye View)
Pillar 2: LLD - Low-Level Design / Schema Design (The Internal Blueprint)
Pillar 3: API Design - The Communication Contract (The Postal Rules)
Pillar 1: HLD - High-Level Design (The Bird's Eye View)
HLD answers the big-picture question: What are the major pieces of this system, and how do they connect? When you do HLD, you are not writing any code. You are drawing a diagram - boxes for components, arrows for data flow. Each box represents a major infrastructure element: a database, a cache, a load balancer, a message queue, a CDN, a set of application servers.
Think of HLD as looking at a city from an airplane. You can see the neighborhoods (services), the highways (network connections), the power plants (servers), the warehouses (databases), and the parks (caches). You cannot see individual houses or plumbing. That level of detail comes later.
HLD decisions include: How many app servers do we need? Should we use SQL or NoSQL? Do we need a cache layer? Where does the CDN sit? Should we split this into microservices or keep it as a monolith? These decisions affect cost, performance, reliability, and the ability to scale. Getting them wrong is extremely expensive to fix later. That is why companies invest heavily in HLD before writing a single line of code.
Pillar 2: LLD - Low-Level Design / Schema Design (The Internal Blueprint)
LLD answers: What does the data look like inside each component? Once HLD says 'we need a database,' LLD designs the database in full detail - tables, columns, data types, primary keys, foreign keys, indexes, constraints, relationships. LLD is also called Schema Design or Data Modeling.
Back to the city analogy: HLD said 'we need a hospital at coordinates X, Y.' LLD is the architect designing the hospital's internal layout: operating rooms on the 3rd floor, emergency entrance on the east side, plumbing rated for 500 daily patients, backup generators in the basement. Every room has a purpose. Every pipe has a diameter. Every wall has a load rating.
LLD decisions include: Should the email column be VARCHAR(255) or TEXT? Do we need an index on created_at for sorting? Is the relationship between users and orders one-to-many or many-to-many? Should we add a composite unique constraint on (user_id, post_id) in the likes table to prevent double-liking? These details feel small, but a missing index can make a query take 30 seconds instead of 3 milliseconds. A wrong data type can corrupt data silently. LLD is where correctness lives.
Pillar 3: API Design - The Communication Contract (The Postal Rules)
API Design answers: How do different parts of the system talk to each other, and how do external clients interact with the system? An API (Application Programming Interface) is a contract. It says: if you send me this kind of request, I will give you this kind of response. Every modern web and mobile application communicates through APIs.
The city's postal system analogy applies perfectly. Every department has an official mailing address (URL). There are rules: letters must be in standard envelopes (request format), must include a return address (authentication), and responses come in standard packaging (response format). If you send a letter to the wrong address or in the wrong format, you get an error notice back (HTTP 400 Bad Request).
API Design decisions include: What URL pattern should this endpoint use? Should this be a GET or a POST? What status code is correct for this scenario (200? 201? 404? 409?)? What fields should the response contain? Should we use cursor-based or offset-based pagination? How do we handle authentication? What happens if the client sends invalid data? Every one of these decisions affects how easy or hard it is for other developers to use your system.
Notice how all three pillars describe the same system (URL shortener) at different zoom levels. HLD shows the big boxes. LLD shows what's inside the database box. API Design shows how the client box talks to the server box. They are three views of one system.
How the Three Pillars Connect - A Real Instagram Walkthrough
Theory is useful, but nothing beats tracing a real user action through all three layers. Let us follow what happens when a user opens Instagram and sees their feed.
Step 1: The User Opens the Instagram App
The Instagram app on the user's phone sends an HTTP request to Instagram's servers. But the app does not know which specific server to talk to. It sends the request to a domain name (api.instagram.com), which resolves via DNS to a load balancer.
HLD relevance: The load balancer is an HLD component. It was chosen because Instagram has thousands of app servers and needs to distribute traffic evenly. Without it, one server would get all the requests and crash while others sit idle.
Step 2: The Load Balancer Routes the Request
The load balancer selects one of the app servers (say, Server #347 out of 2,000) and forwards the request. The selection algorithm might be round-robin (take turns), least-connections (pick the server with the fewest active requests), or IP-hash (same user always goes to the same server).
HLD relevance: Choosing the load balancing algorithm is an HLD decision. IP-hash gives better cache performance (the server remembers the user's data). Round-robin is simpler and more fault-tolerant. The choice depends on the system's requirements.
Step 3: The App Server Checks the Cache
Server #347 receives the request: 'Get the feed for user #8,234,001.' Before querying the main database (slow, 30-50ms), it checks Redis (fast, under 1ms). If the feed was recently generated and cached, it returns immediately. This 'cache hit' path is what makes the app feel instant.
HLD relevance: Putting a cache (Redis) in front of the database is an HLD decision. The decision was made because the feed query is expensive (it joins posts, users, likes, and follows tables) and is requested by the same user many times per session. Caching avoids re-running that expensive query every time.
Step 4: Cache Miss - Query the Database
If the cache does not have the feed (a 'cache miss'), the app server queries PostgreSQL. It runs a query that effectively says: 'Find the most recent 20 posts from all accounts that user #8,234,001 follows, ordered by date, and include the author's username and avatar for each post.'
LLD relevance: This query touches the follows table (to find who the user follows), the posts table (to get recent posts from those accounts), and the users table (to get the author info for each post). The performance of this query depends entirely on the LLD: Are there indexes on follows.follower_id? On posts.author_id and posts.created_at? Is the follows table's primary key (follower_id, following_id)? Every LLD decision directly impacts whether this query takes 3 milliseconds or 30 seconds.
Step 5: The Server Builds and Returns the Response
The app server takes the raw database rows, formats them into JSON, and sends back the HTTP response. The response follows the API contract precisely.
API relevance: The API design determines the exact shape of the response: which fields are included, what they are named, how pagination works (cursor-based, with a next_cursor field so the app can request the next page), and what HTTP status code is returned (200 OK for success).
Notice how all three pillars came into play for one simple user action. HLD determined which components exist and how the request flows. LLD determined how the data is stored and queried efficiently. API Design determined the exact request and response contract. Remove any one pillar and the system either does not work, works slowly, or is impossible for other engineers to build against.
The Complete System Design Jargon Dictionary
System design has a lot of terminology. Beginners often feel lost because articles assume you already know these words. This section defines every term you will encounter, with analogies and examples. Bookmark this section and come back whenever you see a term you do not recognize.
Scalability
The ability of a system to handle increased load without degrading performance. There are two types:
Vertical scaling (scaling up): Making a single server more powerful - more CPU, more RAM, bigger disk. Like replacing a small delivery van with a semi-truck. Simple but has a ceiling. You cannot make one server infinitely powerful.
Horizontal scaling (scaling out): Adding more servers. Like hiring more delivery vans instead of buying a bigger one. More complex to manage, but there is no ceiling. This is what companies like Netflix and Google use. They run thousands to millions of servers.
Latency vs Throughput
These are the two most important performance metrics:
Latency: How long a single request takes from start to finish. Measured in milliseconds (ms). When you click a button and it takes 200ms to respond, that is 200ms of latency. Users notice anything above 100ms. Anything above 1 second feels broken.
Throughput: How many requests the system can handle per second. Measured in requests per second (RPS) or queries per second (QPS). If your server handles 10,000 requests per second, that is its throughput. High throughput and low latency are both important, but they are not the same thing. A system can have high throughput (handles 100K requests/sec) but high latency (each request takes 2 seconds).
Availability and the Nines
Availability is the percentage of time a system is operational. It is measured in 'nines':
Every additional nine is exponentially harder and more expensive to achieve. Going from 99% to 99.9% might cost 2x. Going from 99.99% to 99.999% might cost 10x. System design is about choosing the right availability target for your requirements and designing accordingly.
Consistency, Availability, Partition Tolerance (CAP Theorem)
When a network partition happens, a distributed system can guarantee either Consistency or Availability, but not both.
The diagram below illustrates the core idea behind the CAP Theorem.
Let’s understand each component of CAP Theorem with examples:
Consistency: Every read receives the most recent write. If you update your profile name, the very next request from any server returns the new name.
Availability: Every request receives a response (not an error). The system is always responsive.
Partition Tolerance: The system continues operating even if network communication between servers is lost.
In practice, network partitions happen (servers lose contact), so you must have Partition Tolerance. That leaves you choosing between Consistency and Availability. Banks choose consistency - they would rather show an error than show a wrong account balance. Social media chooses availability - it is acceptable for a like count to be slightly out of date for a few seconds. This trade-off appears in almost every system design discussion.
The Important Reality
Many beginners think:
Why not have C + A + P?
The key reason is that network partitions are inevitable. A partition occurs when communication between nodes in a distributed system is disrupted. Such disruptions can happen due to various reasons, including server failures, network outages, router malfunctions, data center issues, or cloud region connectivity problems.
Since distributed systems operate across multiple machines connected through a network, engineers must assume that partitions can occur at any time. Therefore, Partition Tolerance (P) is not optional; it is a fundamental requirement of any practical distributed system.
CP (Consistency + Partition Tolerance): The system guarantees that users always receive consistent data, even if some requests cannot be served during the partition.
AP (Availability + Partition Tolerance): The system guarantees that requests continue to receive responses, even if some responses contain outdated or temporarily inconsistent data.
CAP Example: User Profile Update
Redundancy and Replication
Redundancy means having backup copies of critical components. If you have only one database server and it crashes, your entire application is down. If you have three copies (replicas), and one crashes, the other two keep serving requests. Replication is the mechanism that keeps those copies synchronized. There are two main approaches:
Synchronous replication: A write is not confirmed until all replicas have it. Guarantees consistency but is slower.
Asynchronous replication: A write is confirmed after the primary has it; replicas catch up in the background. Faster but risks briefly serving stale data if you read from a replica immediately after a write.
Sharding (Horizontal Partitioning)
When a single database server cannot hold all your data or handle all your queries, you split the data across multiple servers. Each server holds a subset of the data. This is called sharding. For example, users with IDs 1-10,000,000 go to Database Shard 1. Users with IDs 10,000,001-20,000,000 go to Shard 2. Each shard handles only its portion of the total traffic. The challenge is choosing a good shard key (the field you split on) and handling queries that need data from multiple shards.
Idempotency
An operation is idempotent if performing it multiple times has the same effect as performing it once. This matters because networks are unreliable. If a user clicks 'Place Order' and the network drops the response, the client might retry. If the operation is not idempotent, the user gets charged twice. Designing idempotent APIs (using techniques like idempotency keys) prevents these bugs.
Rate Limiting
Restricting how many requests a client can make in a given time window. Without rate limiting, a single buggy client or malicious attacker can send millions of requests and crash your system. Rate limiting says: 'You get 1,000 requests per hour. After that, you get HTTP 429 Too Many Requests until the window resets.' This protects your system and ensures fair usage.
Fan-out
Distributing a single request, event, or message to multiple recipients or downstream systems. Instead of handling one destination, the system copies the event and sends it to many places at once. Think of posting a photo on Instagram: one upload triggers updates to thousands or millions of followers' feeds. Fan-out is commonly used in social media feeds, notification systems, analytics pipelines, and event-driven architectures. It improves scalability by allowing one action to power many outcomes, but it can become expensive when the number of recipients is very large. For example, a user with 10 million followers may require the system to distribute a single post to millions of feed entries.
Every Infrastructure Component You Need to Know
These are the building blocks of every system architecture. In an interview, you pick from these components and arrange them into a design. In ScaleDojo's Architecture Lab, these are the actual pieces you drag onto the canvas. Know what each one does, when to use it, and when not to.
1. Client (Browser, Mobile App)
The starting point of every request. The browser or mobile app that the user interacts with. The client does not do heavy computation or store permanent data. It sends requests to the backend and renders whatever the backend sends back. In system design, the client is always the leftmost box in your diagram.
2. DNS (Domain Name System)
The internet's phone book. When you type 'instagram.com' your browser does not know where Instagram's servers are. It asks DNS: 'What IP address does instagram.com point to?' DNS responds: '157.240.1.35.' Now the browser can send the request to the right server. DNS resolution typically takes 20-50ms and is cached for hours. In design diagrams, DNS is usually implied rather than drawn, but it exists behind every domain name.
3. CDN - Content Delivery Network (Cloudflare, CloudFront, Fastly)
A global network of servers that caches static files - images, CSS, JavaScript, fonts, videos - at locations physically close to users around the world. When a user in Tokyo requests a profile photo, instead of fetching it from a data center in Virginia (round-trip time: 180ms), the CDN serves it from an edge node in Tokyo (round-trip time: 15ms). CDNs also absorb DDoS attacks and reduce load on your origin servers by 60-90%.
When to use: Always. Every production system should use a CDN for static assets. There is almost no reason not to.
4. Load Balancer (Nginx, AWS ALB, HAProxy)
Distributes incoming traffic across multiple servers. Without it, a single server handles all traffic and becomes a bottleneck. The load balancer also performs health checks: if a server stops responding, it is automatically removed from rotation, and no user ever sees an error. Think of the host at a restaurant: instead of letting all diners crowd one table, the host seats them evenly across all available tables.
Load balancing algorithms: Round-robin (take turns), Least Connections (send to the server with the fewest active requests), IP Hash (same user always goes to the same server for cache consistency), Weighted (servers with more capacity get more traffic).
5. Application Server (Where Your Code Runs)
The server that executes your business logic. It receives HTTP requests, validates input, applies rules (can this user perform this action?), reads/writes to the database, and sends back HTTP responses. You run many identical copies behind the load balancer. The critical rule: app servers must be stateless. They must not store any user-specific data in memory between requests. Why? Because the next request from the same user might go to a different server. Any data that needs to persist goes in the database or cache.
6. Database - SQL (PostgreSQL, MySQL)
Permanent, structured data storage organized in tables with rows and columns. SQL databases enforce schemas (every row in a table has the same columns), support ACID transactions (changes are atomic, consistent, isolated, and durable), and enable complex queries with JOINs across tables. Use SQL when: data has clear relationships and structure, you need transactions (financial data, inventory), or you need complex queries (reports, analytics). PostgreSQL is the most popular choice for new systems.
7. Database - NoSQL (MongoDB, DynamoDB, Cassandra, Redis)
Non-relational databases optimized for specific access patterns:
Document stores (MongoDB): Store data as flexible JSON-like documents. Each document can have different fields. Great for content management, user profiles with varying attributes, and catalogs.
Key-value stores (Redis, DynamoDB): Lightning-fast lookups by key. Store and retrieve data using a single key. Great for sessions, caching, shopping carts, and real-time leaderboards.
Wide-column stores (Cassandra, HBase): Optimized for write-heavy workloads at massive scale. Rows can have different columns. Great for time-series data, IoT sensor data, and activity logs.
Graph databases (Neo4j): Data modeled as nodes and edges. Great for social networks (who follows whom), recommendation engines, and fraud detection where relationships between entities matter more than the entities themselves.
Rule of thumb: Start with PostgreSQL. Move to NoSQL only when you have a specific access pattern that SQL does not serve well at the scale you need.
8. Cache (Redis, Memcached)
In-memory data store for frequently-accessed data. Reading from a database takes 5-50ms. Reading from a cache takes 0.1-1ms. By storing hot data in the cache, you reduce database load by 80-95% and make the user experience dramatically faster. The cache holds a copy of data that also lives in the database. It is not the source of truth - the database is. If the cache goes down, the system still works (just slower, because every request hits the database).
9. Message Queue (Kafka, RabbitMQ, SQS)
A message queue decouples producers (services that create work) from consumers (services that do the work). The producer publishes a message to the queue and moves on immediately. The consumer picks up the message whenever it is ready and processes it. If the consumer is busy, messages pile up in the queue and get processed later - nothing is lost.
Real example: When you upload a video to YouTube, the server immediately returns 'Upload complete!' But the video is not actually processed yet. The server dropped a message on a queue: 'Process video #12345.' Background workers pick up that message and spend the next 30 minutes encoding the video into 7 quality levels (144p through 4K). You eventually get a notification: 'Your video is ready.' That entire background pipeline is powered by a message queue.
10. Blob Storage (AWS S3, Google Cloud Storage)
Object storage for large binary files - images, videos, PDFs, audio files, ML model weights, database backups. Never store binary files in your database (it bloats the DB, kills performance, and makes backups painful). Store the file in blob storage and save the URL in the database. S3 is absurdly durable: 99.999999999% (11 nines) durability means if you store 10 million objects, you expect to lose one every 10,000 years.
11. Search Engine (Elasticsearch, OpenSearch)
Specialized index for full-text search. Regular databases use B-tree indexes optimized for exact matches (WHERE email = 'ada@example.com'). Search engines use inverted indexes optimized for text search - finding documents that contain 'sunset beach vibes' even when no single document has that exact phrase. Elasticsearch handles typos (fuzzy matching), synonyms, relevance ranking, and can search through billions of documents in milliseconds.
12. API Gateway (Kong, AWS API Gateway)
The front door for all external API requests. It handles authentication (is this a valid user?), rate limiting (is this user sending too many requests?), request routing (which internal service handles this URL?), and protocol translation. Instead of exposing 15 internal microservices to the internet, you expose one API Gateway. It is the hotel front desk that coordinates all departments behind the scenes.
13. Monitoring and Alerting (Prometheus, Grafana, Datadog)
Collects metrics from every component: CPU utilization, memory usage, request latency (p50, p95, p99), error rate, queue depth, cache hit ratio, database connection pool usage. Displays dashboards and fires alerts when thresholds are crossed. Without monitoring, your first notification of an outage is an angry tweet from a user. With monitoring, you get paged at 3 AM when the error rate crosses 1%, fix it, and the user never notices.
Full Worked Example: Designing Instagram from Scratch
Let us put everything together. We will design a simplified Instagram across all three pillars. This is the kind of exercise you will do in system design interviews and in ScaleDojo's labs.
Requirements
Users can register, log in, and edit their profile (username, bio, avatar).
Users can upload photos with captions.
Users can follow and unfollow other users.
Users see a feed of photos from people they follow, sorted by recency.
Users can like and comment on photos.
Scale target: 150 million daily active users. 500 million photos stored. 10,000 new photos uploaded per minute at peak.
HLD: The Architecture
Why each component was chosen
CDN: Photos are requested billions of times. Serving them from origin servers would be slow and absurdly expensive. CDN caches them at edge nodes globally.
Load Balancer: 150M daily users means thousands of requests per second. One server cannot handle that. The load balancer distributes traffic across 50-200 app servers.
App Servers (stateless): Multiple identical copies. If one crashes, the load balancer routes to others. No data stored in server memory between requests.
PostgreSQL: Structured data with clear relationships (users have posts, posts have likes). Needs ACID transactions (a user cannot like the same post twice). Supports the complex JOINs needed for feed generation.
Redis Cache: Feed queries are expensive (joining follows + posts + users). Cache the feed for each user. Cache hit ratio target: 90%+ (meaning 9 out of 10 feed requests are served from cache without touching the database).
S3 Blob Storage: Photo files range from 500KB to 10MB. Storing them in PostgreSQL would bloat the database and kill backup performance. S3 is designed for exactly this - cheap, durable, scalable object storage.
Kafka Message Queue: When a user posts a photo, we need to: update followers' feed caches, send push notifications, index the photo in search. Doing all of this during the upload request would make it take 10+ seconds. Instead, the app server publishes an event to Kafka and responds immediately. Background workers handle the rest asynchronously.
Elasticsearch: Users search by caption and hashtag. PostgreSQL's LIKE queries are slow for full-text search. Elasticsearch uses inverted indexes optimized for this exact use case.
LLD: The Database Schema
API Design: The Endpoints
That is Instagram, designed across all three pillars. The HLD shows the architecture. The LLD shows the exact database structure (with explanations for every design choice). The API shows the communication contract between client and server. This is precisely the kind of multi-layered thinking that system design interviews test.
What a System Design Interview Actually Looks Like
Most system design interviews are 45-60 minutes. Here is the exact structure that strong candidates follow:
The interviewer is not looking for a perfect answer. They are evaluating: Do you clarify before assuming? Do you think about trade-offs? Do you know why each component exists? Can you identify bottlenecks? Do you communicate clearly? System design interviews are fundamentally about structured thinking, not memorized architectures.
How ScaleDojo Helps You Practice All Three Pillars
Reading about system design is helpful but insufficient. You would not learn to swim by reading a book about swimming. You learn by getting in the water. ScaleDojo is the swimming pool.
ScaleDojo provides three dedicated labs, each targeting one of the three pillars:
Architecture Lab (HLD Practice)
You receive a real-world scenario: 'Design a URL shortener like bit.ly for 100M monthly users.' You select infrastructure components (CDN, Load Balancer, App Servers, PostgreSQL, Redis, S3, Kafka...), place them on a canvas, and draw data flow arrows showing how a request travels through the system. When you submit, the AI scoring engine evaluates your design across multiple dimensions: component completeness (did you include everything needed?), data flow correctness (do the arrows make sense?), scalability (can this handle the stated load?), and cost efficiency. The feedback tells you exactly what you got right and what you missed.
Schema Design Lab (LLD Practice)
Story-driven challenges with movie themes. Level 1 might ask you to design the database for a passenger manifest (think Titanic). You create tables, define columns with specific data types, set primary keys and foreign keys, add UNIQUE constraints and indexes, and draw relationships between tables. The engine validates your schema against the canonical solution and shows a detailed diff. You see exactly which columns you got right, which you missed, and which indexes you should have added.
API Design Lab (REST Practice)
Progressive levels that start with basic CRUD endpoints and advance through authentication, pagination, error handling, nested resources, GraphQL, and gRPC. You receive a scenario, design the endpoints (method, URL, request body, response shape, status codes), and submit. The scorer evaluates resource naming, HTTP method correctness, status code accuracy, pagination design, and authentication coverage.
Built-in AI Tools
AI Hints: When you are stuck for more than 10 minutes, the hint system gives you a targeted nudge in the right direction without spoiling the full answer. Think of it as a mentor saying 'Have you considered what happens when two users try to register the same username simultaneously?' rather than giving you the entire schema.
AI Analysis: After submitting your design, the analysis engine gives you a thorough review of every decision you made. It identifies strengths, explains weaknesses, and suggests specific improvements. This is the closest thing to having an expert review your work.
Roadmap: A curated learning path that maps topics to specific lab levels. If you are not sure where to start or what to practice next, the roadmap tells you. It covers: beginner foundations, intermediate scaling, advanced distributed systems, and interview preparation.
Your Action Plan - What to Do Right Now
You have just read the most comprehensive overview of system design available. Here is exactly how to turn that knowledge into skill:
Read the HLD Beginner Blueprint (/blogs/hld-high-level-design-complete-beginner-blueprint). It explains every component in full detail with worked examples.
Read the LLD Beginner Blueprint (/blogs/lld-low-level-design-complete-beginner-blueprint). It teaches database design from absolute zero through advanced patterns.
Read the API Design Beginner Blueprint (/blogs/api-design-complete-beginner-blueprint-rest-to-production). It covers HTTP methods, status codes, URL design, pagination, auth, and versioning.
Read How All Three Connect (/blogs/how-hld-lld-and-api-design-work-together). It shows how decisions in one pillar force changes in the others.
Start the 7-Day Practice Plan (/blogs/your-first-7-days-in-scaledojo-beginner-hand-holding-plan). Day 1: Architecture Lab Levels 1-2. Day 2: LLD Lab Levels 1-2. Day 3: API Lab Levels 1-2. And so on.
Submit imperfect designs. Do not wait until you think your answer is perfect. Submit, read feedback, learn, improve. That cycle is where real learning happens.
When stuck for more than 15 minutes, use the hint system. It exists for a reason. Your time is valuable.
Continue Reading
HLD In Depth: /blogs/hld-high-level-design-complete-beginner-blueprint
LLD In Depth: /blogs/lld-low-level-design-complete-beginner-blueprint
API Design In Depth: /blogs/api-design-complete-beginner-blueprint-rest-to-production
How All Three Connect: /blogs/how-hld-lld-and-api-design-work-together
Your 7-Day Practice Plan: /blogs/your-first-7-days-in-scaledojo-beginner-hand-holding-plan
System design is not a talent. It is a skill. Skills are built through deliberate practice, not passive reading. You now have the map. ScaleDojo gives you the practice ground. The only thing standing between you and mastery is the decision to start. Open a lab. Pick a level. Submit your first imperfect design. That is how every expert began.