Core Building Blocks
Master the building blocks of system design — load balancers, caches, CDNs, message queues, API gateways, and the components you'll use in every system design interview.
Premium Course Content
This lesson is part of a premium course. Upgrade to Pro to unlock all premium courses and content.
- Access all premium courses
- 1000+ AI skill templates included
- New content added weekly
🔄 Quick Recall: In the previous lesson, you learned estimation — the math that determines your system’s scale. Now you’ll learn the building blocks — the components you’ll use in every system design to handle that scale.
Building blocks are the reusable components that appear in almost every system design. Understanding when and why to use each one — not just what they do — is what separates strong candidates from candidates who just draw boxes.
Building Blocks Overview
| Block | What It Does | When To Use | Key Trade-off |
|---|---|---|---|
| Load Balancer | Distributes traffic across servers | Multiple servers handling the same request type | Adds latency hop; single point of failure unless redundant |
| Cache | Stores frequently accessed data in memory | Read-heavy workloads (>10:1 read/write ratio) | Stale data; cache invalidation complexity |
| CDN | Serves static content from edge locations | Static assets (images, CSS, JS) or cacheable API responses | Cache invalidation delay; cost per request |
| Message Queue | Decouples producers from consumers | Async processing, different processing speeds | Eventual consistency; added infrastructure |
| API Gateway | Single entry point for clients | Multiple microservices; authentication, rate limiting | Added latency; single point of failure |
| Rate Limiter | Controls request rate per user/IP | Preventing abuse, protecting downstream services | Legitimate users may be throttled during traffic spikes |
Caching Deep Dive
AI prompt for caching design:
Design the caching strategy for [SYSTEM]. Read/write ratio: [X:1]. Data size: [Y]. Latency requirements: [Z]. Help me decide: (1) What to cache (which data, what percentage), (2) Cache pattern — cache-aside, write-through, write-behind, (3) Cache size and TTL, (4) Invalidation strategy — TTL expiry, event-driven invalidation, or both, (5) What happens on cache miss (thundering herd protection), (6) What happens when the cache goes down (graceful degradation).
Caching patterns:
| Pattern | How It Works | Best For |
|---|---|---|
| Cache-Aside | App reads cache first; on miss, reads DB and populates cache | General purpose, read-heavy |
| Write-Through | App writes to cache AND DB simultaneously | Data that’s read immediately after writing |
| Write-Behind | App writes to cache; cache writes to DB asynchronously | Write-heavy, can tolerate brief inconsistency |
| Read-Through | Cache automatically loads from DB on miss | When cache manages its own data loading |
Message Queues
AI prompt for queue design:
Design the message queue architecture for [SYSTEM]. Use cases: [LIST — e.g., “order processing, email notifications, analytics events”]. For each use case: (1) Which queue pattern — point-to-point or pub/sub, (2) Delivery guarantee — at-most-once, at-least-once, or exactly-once, (3) Ordering requirements — does message order matter? (4) Dead letter queue — what happens to messages that fail processing, (5) Consumer scaling — how many consumers, how to avoid duplicate processing.
✅ Quick Check: Your system uses a message queue for order processing. The queue has 3 consumers. A message for Order #123 is picked up by Consumer A, which crashes before completing processing. What happens to Order #123? (Answer: It depends on the acknowledgment model. With auto-ack, the message is lost (at-most-once). With manual-ack, the message returns to the queue after a timeout and is picked up by Consumer B (at-least-once). For order processing, you need at-least-once + idempotent processing to ensure every order is processed exactly once even if a consumer crashes.)
CDN and Static Content
AI prompt for CDN strategy:
Design the CDN strategy for [SYSTEM]. Content types: [LIST — images, videos, CSS/JS, API responses]. Generate: (1) What to serve from CDN (static vs. dynamic), (2) Cache TTL per content type, (3) Cache invalidation strategy (purge, versioned URLs, stale-while-revalidate), (4) Origin shield configuration, (5) Estimated bandwidth savings.
Key Takeaways
- Cache strategically based on access patterns: 20% of data serves 80% of reads (Pareto principle) — cache that 20% and one Redis instance can replace 9 database replicas, reducing cost by 90%
- Load balancing algorithm matters when requests have different costs: round-robin assumes equal requests, least-connections adapts to actual server load — always explain why you chose a specific algorithm
- Message queues decouple synchronous user-facing operations from slow asynchronous side effects: the user gets a fast response (50ms) while email, analytics, and notifications process asynchronously
- For every building block, state the trade-off: caching trades consistency for speed, message queues trade immediacy for reliability, CDNs trade freshness for latency. Interviewers want to hear what you’re giving up
- AI explains each building block at your level and helps you practice justifying component selection: “I added a cache because our 100:1 read/write ratio and 50K QPS makes database reads the bottleneck”
Up Next
In the next lesson, you’ll learn data storage — choosing between SQL and NoSQL, designing schemas, sharding strategies, and the database decisions that determine your system’s scalability.