Langsung ke konten

Konten utama halaman ini berbahasa Inggris.Terjemahkan halaman ini

Keahlian & teknologi

System Design roadmap

System design is planning how the parts of a large software system fit together: servers, databases, caches, queues and how they handle millions of users and failures. It's essential for senior roles and every backend or architect interview.

Waktu
⏱ 8–10 weeks
Level
Advanced
Steps
6 steps
Architecture ↓Cheat sheet ↓5 interview Q&As ↓
Bagikan

The roadmap

Click a step to open the full guide.

Best architecture: a scalable web application

The default shape for most large web and mobile backends. Start simpler, and add pieces as load grows.

Reference architecture

  1. Clients (web, mobile)
  2. DNS + CDN (static files, edge cache)
  3. Load balancer / API gateway (TLS, rate limits)
  4. Stateless app servers (autoscaled)
  5. Cache (Redis) · Message queue → workers
  6. Primary database + read replicas · Object storage
  7. Monitoring, logs, traces

Why it's built this way

  • CDN serves static content near users and absorbs traffic.
  • Stateless app servers let you add machines freely behind the load balancer.
  • Cache removes most database reads for hot data.
  • Queue + workers move slow work (emails, video, AI) out of the request path.
  • Read replicas scale reads; sharding only when one primary can't keep up.
  • Observability everywhere: you can't fix what you can't see.

System Design cheat sheet

The essentials on one screen. Bookmark it for revision.

Numbers to know

Memory read~100 ns
SSD read~100 µs
Same-region network round trip~0.5–1 ms
Cross-continent round trip~100–150 ms
Seconds in a day86,400
99.9% / 99.99% uptime~8.8 h / ~53 min down per year

Building block → use

CDNStatic files, edge caching
Load balancerSpread traffic, health checks
CacheHot reads, sessions
QueueAsync work, spikes
ReplicasRead scaling, failover
ShardingWrite/storage scaling
Object storageImages, video, backups

Improve performance

  • Cache at every layer: CDN, application cache, database cache.
  • Make services stateless and scale horizontally.
  • Use async processing for anything not needed in the response.
  • Denormalise or precompute for read-heavy paths (feeds, dashboards).
  • Measure p95/p99 latency and remove the biggest bottleneck first.

Security checklist

  • Authenticate at the gateway; authorise in every service.
  • Encrypt in transit (TLS) and at rest.
  • Rate limit and protect against abuse/DDoS at the edge.
  • Least-privilege access between services; secrets in a vault.
  • Audit logs for sensitive actions.

Most important interview questions

Click a question to see a strong answer. Each step also has its own questions.

1How do you scale a database?

Indexes and query tuning first, then caching, read replicas, vertical scaling, and finally sharding/partitioning; choose NoSQL for specific high-scale access patterns.

2Explain the CAP theorem with an example.

During a network partition you choose consistency (reject some requests, e.g. bank balances) or availability (serve possibly stale data, e.g. social likes).

3Monolith vs microservices for a new product?

Usually start with a modular monolith for speed and simplicity; extract services when team or scaling needs justify it.

4How do you design for high availability?

Redundancy across zones, health checks and automatic failover, no single points of failure, graceful degradation, backups and tested recovery.

5Push vs pull for a news feed?

Push (fan-out on write) precomputes feeds for fast reads; pull computes on read. Hybrids push for normal users and pull for celebrities with huge follower counts.

Related roadmap

6

Software Architect

6 steps · 6–12 months (for experienced developers) · Advanced

Lead technical design across teams and systems.

View roadmap →
6

Backend Developer

6 steps · 5–6 months · Intermediate

Build the APIs, databases and services behind apps.

View roadmap →
6

Cloud Engineer

6 steps · 5–7 months · Intermediate

Design, build and run systems on AWS, Azure or Google Cloud.

View roadmap →
6

DSA (Data Structures & Algorithms)

6 steps · 10–14 weeks · Intermediate

Crack coding interviews and write efficient code.

View roadmap →
1

System Design · Step 1 of 6 · 1 week

Fundamentals and estimation

The vocabulary and the maths of scale.

Start every design with numbers: how many users, requests per second, data per day. Rough estimates decide whether you need one server or a thousand.

Horizontal scaling (more machines) needs stateless services, so any server can handle any request.

What you'll learn

  • Latency vs throughput
  • Availability (nines)
  • Back-of-the-envelope estimates
  • Vertical vs horizontal scaling
  • Stateless services

Back-of-the-envelope

  1. Users/day
  2. × actions
  3. ÷ 86,400
  4. × peak factor
  5. = peak QPS

Key concepts

QPS
Queries per second: the load your system must handle.
Availability
Share of time a system works; 99.99% ≈ 53 minutes down a year.
Stateless
Servers keep no user data between requests, so any server can serve anyone.

Step by step

  1. 1.1

    Gather numbers

    Daily users, actions per user, read/write ratio, data size.

  2. 1.2

    Convert to QPS

    Requests per day ÷ 86,400 × peak factor (2–10×).

  3. 1.3

    Estimate storage

    Items per day × size × retention.

Notes

  • 1 day ≈ 86,400 seconds, so 1M requests/day ≈ 12 per second on average (plan for peaks).
  • 99.9% uptime ≈ 8.8 hours downtime a year.

Tips & tricks

  • Round aggressively; the goal is the order of magnitude.

Interview questions

Estimate the QPS for 10M daily users making 20 requests each.

200M requests/day ÷ 86,400 ≈ 2,300 QPS average; with a 3–5× peak, plan for roughly 7,000–12,000 QPS.

The quick way to study this

Memorise a few latency and size numbers and practise 5 estimates.

2

System Design · Step 2 of 6 · 2 weeks

Core building blocks

The parts every large system is made of.

Load balancers spread traffic; caches serve hot data fast; queues decouple slow work; CDNs serve content near users; object storage holds files cheaply. Knowing when to use each is most of system design.

What you'll learn

  • DNS and CDNs
  • Load balancers
  • Caches (Redis)
  • Message queues
  • Object storage
  • API gateways

Request path

  1. Client
  2. DNS
  3. CDN
  4. Load balancer
  5. App server
  6. Cache → DB

Key concepts

Load balancer
Spreads requests across servers and removes unhealthy ones.
Cache-aside
App reads cache first; on a miss, loads from the DB and fills the cache.
Message queue
Buffer that lets services work at their own pace.

Step by step

  1. 2.1

    Traffic

    DNS → CDN → load balancer → app.

  2. 2.2

    Kecepatan

    Cache hot reads; CDN for static and edge caching.

  3. 2.3

    Decoupling

    Queues between producers and slow consumers.

Notes

  • Cache what's read often and changes rarely.
  • Queues absorb traffic spikes.

Tips & tricks

  • For each block, learn one failure mode and how to handle it.

Interview questions

What are common cache eviction policies?

LRU (least recently used, most common), LFU (least frequently used) and TTL-based expiry. Choose by access pattern.

The quick way to study this

Draw each block with what goes in, what comes out and how it fails.

3

System Design · Step 3 of 6 · 2 weeks

Data: databases, replication and sharding

Store and scale data correctly.

Pick storage by access pattern. Replication copies data for read scaling and failover; sharding splits data across machines when one can't hold it. The partition key decides whether load spreads evenly.

What you'll learn

  • SQL vs NoSQL
  • Indexes
  • Replication (leader-follower)
  • Sharding and partition keys
  • Consistency models
  • CAP and PACELC

Leader–follower replication

Leader (writes)
  • Follower 1 (reads)
  • Follower 2 (reads)
  • Follower 3 (standby)

Key concepts

Replication lag
Followers may be slightly behind the leader.
Sharding
Splitting data across machines by a partition key.
Consistent hashing
Distributes keys so adding a node moves only a few keys.

Step by step

  1. 3.1

    Choose storage

    Relational for transactions; key-value/wide-column for huge simple workloads.

  2. 3.2

    Replicate

    Leader for writes, followers for reads and failover.

  3. 3.3

    Shard

    Split by a key that spreads load evenly (e.g. user_id hash).

Notes

  • Bad partition keys create hot spots.
  • Strong consistency costs latency; eventual consistency costs simplicity.

Tips & tricks

  • Say which consistency each feature needs (payments: strong; likes count: eventual).

Interview questions

How would you shard a users table?

Hash the user_id (or use consistent hashing) to pick a shard so load spreads evenly; keep a user's related data on the same shard to avoid cross-shard joins.

The quick way to study this

Compare 3 databases by data model, consistency and scaling.

4

System Design · Step 4 of 6 · 1 week

Reliability and distributed patterns

Keep working when parts fail.

In large systems something is always failing. Design for it: timeouts on every call, retries with backoff, idempotent operations so retries are safe, and circuit breakers to stop cascading failures.

What you'll learn

  • Redundancy and failover
  • Retries, timeouts, backoff
  • Idempotency
  • Circuit breakers
  • Rate limiting
  • Event-driven architecture

Retry with backoff

  1. Call service
  2. Timeout/failure?
  3. Wait (backoff + jitter)
  4. Retry (max N)

Repeats as a loop

Key concepts

Circuit breaker
Stops calling a failing service for a while so failures don't cascade.
Token bucket
Rate-limiting algorithm: tokens refill steadily; each request spends one.
Idempotency key
Unique request ID so repeats are ignored.

Step by step

  1. 4.1

    Fail safely

    Timeouts and retries with exponential backoff and jitter.

  2. 4.2

    Retry safely

    Idempotency keys for writes.

  3. 4.3

    Protect

    Circuit breakers and rate limiting.

Notes

  • Retries without idempotency can double-charge customers.

Tips & tricks

  • For every arrow in your diagram, ask: what if this call fails or is slow?

Interview questions

Design a rate limiter.

Token bucket per user/API key stored in Redis (atomic operations), applied at the API gateway; return 429 with Retry-After; consider sliding-window counters for accuracy.

The quick way to study this

Learn the 6 patterns and where each fits.

5

System Design · Step 5 of 6 · 1 week

The interview framework

A repeatable 45-minute structure.

Interviewers judge your process as much as your design. Spend the first minutes on requirements and scale, then sketch the high-level design, then go deep on the hardest parts, and finish with trade-offs and how you'd evolve the design.

What you'll learn

  • Clarify requirements
  • Estimate scale
  • API and data model
  • High-level design
  • Deep dives
  • Trade-offs and bottlenecks

45-minute framework

  1. Requirements
  2. Estimates
  3. API + data model
  4. High-level design
  5. Deep dives
  6. Trade-offs

Key concepts

Functional requirement
What the system does (post a message).
Non-functional requirement
How well it does it (latency, availability, scale).

Step by step

  1. 5.1

    Requirements (5 min)

    Functional, non-functional, scale, out of scope.

  2. 5.2

    High level (15 min)

    APIs, data model, main components.

  3. 5.3

    Deep dive (20 min)

    Bottlenecks, scaling, failure handling.

  4. 5.4

    Wrap up (5 min)

    Trade-offs and future improvements.

Notes

  • Never jump to boxes before agreeing requirements.

Tips & tricks

  • Talk through trade-offs out loud; there is no single right answer.

Interview questions

What do interviewers look for in system design?

Clarifying requirements, structured thinking, sensible building blocks, awareness of bottlenecks and failures, and clear trade-off reasoning, not one perfect answer.

The quick way to study this

Practise the framework on one problem a day for a week.

6

System Design · Step 6 of 6 · 2 weeks

Classic designs and AI systems

Practise the problems interviewers ask.

Practise a set of classic problems; each teaches different building blocks. Increasingly, interviews include AI systems: an LLM-powered assistant with RAG, caching, rate limits, evaluation and cost control.

What you'll learn

  • URL shortener
  • Chat / messaging
  • News feed
  • Rate limiter
  • Video streaming
  • RAG / AI assistant at scale

AI assistant at scale

  1. Client + streaming
  2. API gateway (auth, rate limits)
  3. Orchestrator (prompting, tools)
  4. RAG: search + vector DB · Model gateway
  5. Cache · Eval & monitoring · Cost tracking

Key concepts

Fan-out on write
Push posts to followers' feeds when posted (fast reads, costly for celebrities).
WebSocket
A persistent two-way connection for real-time updates.

Step by step

  1. 6.1

    URL shortener

    ID generation, key-value store, caching, redirects.

  2. 6.2

    Chat

    WebSockets, message storage, delivery status, fan-out.

  3. 6.3

    News feed

    Fan-out on write vs read; ranking.

  4. 6.4

    AI assistant

    RAG, model gateway, caching, rate limits, evals.

Notes

  • Chat → WebSockets and fan-out; feed → precompute vs compute on read; rate limiter → token bucket.

Tips & tricks

  • Record yourself and review where you hesitated.

Interview questions

Design a chat application like WhatsApp.

Clients hold WebSocket connections to chat servers; messages go through a queue and are stored (partitioned by conversation); presence via heartbeats; offline users get push notifications; media in object storage via CDN; end-to-end encryption on devices.

The quick way to study this

Design one classic system every two days, out loud, in 45 minutes.

RAG roadmap →

Bagikan halaman ini