Capstone
Week 10 Capstone: The Grand Finale
System Design Mastery Series — The Complete Journey
🎯 The Final Interview
Ten weeks. Fifty lessons. Thousands of concepts. One final test.
You've learned to think like a senior engineer. Now prove it.
The Interview Begins
You walk into the interview room for the final round. The whiteboard is blank. The interviewer smiles — this is the principal engineer, someone who's built systems at massive scale.
Interviewer: "Welcome. I've heard great things about your preparation. Today, we're going to design something ambitious — a system that will test everything you know about distributed systems, reliability, and operational excellence."
They turn to the whiteboard and write:
╔═════════════════════════════════════════════════════════════════════════╗
║ ║
║ Design a Global Real-Time Bidding Platform ║
║ ║
║ You're building the ad-tech infrastructure for a company that ║
║ serves 10 billion ad requests per day across 6 continents. ║
║ ║
║ When a user loads a webpage, your system has 100ms to: ║
║ 1. Receive the bid request ║
║ 2. Query multiple demand-side platforms (DSPs) ║
║ 3. Run an auction ║
║ 4. Return the winning ad ║
║ ║
║ Requirements: ║
║ • 100ms end-to-end latency (p99) ║
║ • 99.99% availability (52 minutes downtime/year) ║
║ • Support 500,000 requests per second at peak ║
║ • Real-time budget tracking (can't overspend) ║
║ • Fraud detection (block invalid traffic) ║
║ • Complete audit trail for billing ║
║ ║
╚═════════════════════════════════════════════════════════════════════════╝
Interviewer: "This is one of the most demanding system design problems in our industry. Take your time. Think out loud. I'm interested in your approach as much as your solution."
You take a deep breath. This is it — everything you've learned comes together now.
Phase 1: Requirements Clarification
Before touching the whiteboard, you pause. Week 1 taught you: never assume.
You: "Before I dive in, I'd like to clarify some requirements. This will help me make the right trade-offs."
Interviewer: "Of course. Good instinct."
Your Questions
You: "First, let me understand the traffic pattern. You mentioned 10 billion requests per day and 500K peak RPS. What's the average RPS, and how bursty is the traffic?"
Interviewer: "Average is about 120,000 RPS. Peak happens during major events — Super Bowl, World Cup — where we might see 4-5x normal traffic for a few hours. There's also daily seasonality: traffic is 2x higher during evening hours in each timezone."
You: "For the 100ms latency requirement — is that from when we receive the request to when we return the response? And what happens if we can't meet it?"
Interviewer: "Yes, end-to-end. If you miss the deadline, the ad exchange moves on without you — you lose that impression. Speed is revenue."
You: "How many DSPs do we need to query for each request?"
Interviewer: "Typically 5-10 DSPs per request, depending on the ad slot. Each DSP has their own latency characteristics — some respond in 20ms, some take 80ms."
You: "For budget tracking, what's the tolerance for overspend?"
Interviewer: "Advertisers set daily budgets. We absolutely cannot exceed budget by more than 0.1%. At our scale, even small percentage errors mean real money."
You: "What about geographic distribution of traffic?"
Interviewer: "Roughly: 40% Americas, 35% Europe, 20% Asia-Pacific, 5% rest of world. We need low latency everywhere."
You: "Last question: what data do we need for the audit trail, and how long must we retain it?"
Interviewer: "Every bid request, every response, every auction result. 7 years retention for compliance. This is billions of events per day."
Requirements Summary
You turn to the whiteboard and write:
Functional Requirements:
1. BID REQUEST HANDLING
• Receive bid request from ad exchanges
• Parse and validate request (user context, ad slot info)
• Enrich with user data (if available, privacy-compliant)
2. DSP ORCHESTRATION
• Fan out to 5-10 DSPs per request
• Collect bids within timeout
• Handle partial responses gracefully
3. AUCTION ENGINE
• Run second-price auction
• Apply business rules (frequency caps, brand safety)
• Select winning bid
4. BUDGET MANAGEMENT
• Track spend in real-time
• Enforce daily/campaign budgets
• Pace delivery throughout the day
5. FRAUD DETECTION
• Detect invalid traffic (bots, click farms)
• Block suspicious requests
• Minimize false positives (lost revenue)
6. AUDIT & BILLING
• Log every transaction
• Support billing reconciliation
• 7-year retention
Non-Functional Requirements:
LATENCY
• End-to-end p99: < 100ms
• DSP timeout: 80ms (must leave margin)
• Internal processing: < 20ms
THROUGHPUT
• Average: 120,000 RPS
• Peak: 500,000 RPS
• Must handle 5x spikes
AVAILABILITY
• 99.99% uptime
• 52 minutes/year max downtime
• No single points of failure
CONSISTENCY
• Budget: Strong consistency (can't overspend)
• Auction: Eventual consistency OK
• Audit: Durable, ordered
DATA SCALE
• 10 billion events/day
• 7 years retention
• ~25 PB total storage
Interviewer: "Excellent requirements gathering. You've identified the key constraints. Now show me the architecture."
Phase 2: Back of the Envelope Estimation
You: "Let me validate these numbers and derive some infrastructure requirements."
Traffic Calculations
REQUESTS PER SECOND
Daily requests: 10,000,000,000
Seconds per day: 86,400
Average RPS: ~116,000 (matches interviewer's 120K)
Peak multiplier: ~4x
Peak RPS: ~500,000 ✓
Per-region peak (assuming 40% in Americas):
Americas peak: 200,000 RPS
Europe peak: 175,000 RPS
APAC peak: 100,000 RPS
Data Volume Calculations
STORAGE REQUIREMENTS
Per bid request (raw):
• Request metadata: ~2 KB
• DSP responses (10): ~5 KB
• Auction result: ~1 KB
• Total per request: ~8 KB
Daily storage:
• 10B requests × 8 KB = 80 TB/day
Annual storage:
• 80 TB × 365 = 29 PB/year
7-year retention:
• ~200 PB total
• Need tiered storage (hot/warm/cold)
Infrastructure Estimates
COMPUTE REQUIREMENTS
Assuming each server handles 5,000 RPS at 70% utilization:
Peak servers needed: 500,000 / 5,000 = 100 servers
With 50% headroom: 150 servers globally
Per region:
• Americas: 60 servers
• Europe: 50 servers
• APAC: 30 servers
• Other: 10 servers
Latency Budget
100ms LATENCY BUDGET
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ Request Parse & DSP Fan-out Auction Response │
│ Receive Validate & Collect Engine Send │
│ │
│ [ 2ms ] [ 5ms ] [ 75ms ] [ 10ms ] [ 3ms ] │
│ └──────────────────────────────────────────────────────┘ │
│ 95ms total │
│ 5ms buffer for variance │
│ │
│ DSP TIMEOUT: 70ms (must return by 80ms to leave margin) │
│ │
└─────────────────────────────────────────────────────────────────────┘
Interviewer: "Good. The latency budget is particularly insightful. Now, show me the system."
Phase 3: High-Level Architecture
You: "Let me draw the complete architecture, then we'll dive deep into each component."
System Architecture
┌─────────────────────────────────────────────────────────────────────────────┐
│ GLOBAL RTB PLATFORM │
│ │
│ GLOBAL LAYER │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Route53 │ │ CloudFront │ │ Global │ │
│ │ GeoDNS │────────▶│ (TLS) │────────▶│ Config │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │
│ ┌────────────────────────┼────────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ US-EAST │ │ EU-WEST │ │ AP-SOUTH │ │
│ │ REGION │ │ REGION │ │ REGION │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
REGIONAL ARCHITECTURE
(Each region identical)
┌─────────────────────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ EDGE LAYER │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ NLB │ │ NLB │ │ NLB │ (Network LBs) │ │
│ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │
│ │ └───────────────┼───────────────┘ │ │
│ │ ▼ │ │
│ │ ┌───────────────────────────────┐ │ │
│ │ │ RATE LIMITER │ (Token bucket/region) │ │
│ │ │ + FRAUD FILTER │ (ML-based filtering) │ │
│ │ └───────────────┬───────────────┘ │ │
│ │ │ │ │
│ └────────────────────────┼────────────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ BIDDING LAYER │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────────────┐ │ │
│ │ │ BID ORCHESTRATOR FLEET │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │
│ │ │ │ Orch 1 │ │ Orch 2 │ │ Orch 3 │ │ Orch N │ │ │ │
│ │ │ │ │ │ │ │ │ │ ... │ │ │ │
│ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ └───────────┴─────┬─────┴───────────┘ │ │ │
│ │ │ │ │ │ │
│ │ └─────────────────────────┼────────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌──────────────┴──────────────┐ │ │
│ │ ▼ ▼ │ │
│ │ ┌──────────────────┐ ┌──────────────────┐ │ │
│ │ │ DSP GATEWAY │ │ AUCTION ENGINE │ │ │
│ │ │ │ │ │ │ │
│ │ │ Fan-out to DSPs │ │ Second-price │ │ │
│ │ │ Timeout mgmt │ │ Business rules │ │ │
│ │ │ Circuit breaker │ │ Winner select │ │ │
│ │ └──────────────────┘ └──────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────┼────────────────────────────────────────┐ │
│ │ ▼ │ │
│ │ DATA LAYER │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Redis │ │ Budget │ │ User │ │ Config │ │ │
│ │ │ Cluster │ │ Store │ │ Store │ │ Store │ │ │
│ │ │ (cache) │ │ (strong) │ │ (cache) │ │ (replicated)│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────┼────────────────────────────────────────┐ │
│ │ ▼ │ │
│ │ ASYNC PIPELINE │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Kafka │──▶│ Flink │──▶│ S3 │──▶│ Redshift│ │ │
│ │ │ Events │ │ Streaming│ │ Parquet │ │ /Presto │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Request Flow
You: "Let me trace a single request through the system..."
BID REQUEST LIFECYCLE (Target: 100ms)
Time Budget
▼
0ms ────────────────────────────────────────────────────── 100ms
│ │
▼ ▼
① REQUEST ARRIVES (0-2ms)
│
│ Publisher's webpage loads
│ Ad exchange sends bid request
│ GeoDNS routes to nearest region
│ NLB receives request
│
▼
② EDGE PROCESSING (2-7ms)
│
│ Rate limiter checks quota
│ Fraud filter runs ML model (pre-trained, < 1ms inference)
│ Request validated and parsed
│ Enriched with cached user data
│
▼
③ DSP FAN-OUT (7-77ms)
│
│ Orchestrator selects relevant DSPs (5-10)
│ Parallel requests to all DSPs
│ 70ms timeout (hard deadline)
│ Collect responses as they arrive
│ Circuit breakers protect against slow DSPs
│
▼
④ AUCTION (77-92ms)
│
│ Run second-price auction on collected bids
│ Apply frequency caps, brand safety rules
│ Check budget (CRITICAL: strong consistency)
│ Reserve budget atomically
│ Select winner
│
▼
⑤ RESPONSE (92-97ms)
│
│ Format winning ad response
│ Sign response for verification
│ Send to ad exchange
│
▼
⑥ ASYNC LOGGING (fire-and-forget)
│
│ Publish to Kafka (non-blocking)
│ Event contains: request, all bids, winner, timing
│ Downstream: billing, analytics, fraud ML training
│
▼
DONE: ~95ms average, ~100ms p99
Interviewer: "Good overview. Let's dive into the hard parts. Tell me about budget management — how do you guarantee we never overspend?"
Phase 4: Deep Dives
Deep Dive 1: Real-Time Budget Management
Week 1 concepts: Partitioning, consistency. Week 5 concepts: Distributed transactions.
You: "Budget management is one of the hardest problems here. Let me explain why, and then the solution."
The Challenge:
WHY BUDGET IS HARD
Scenario:
• Advertiser has $10,000 daily budget
• Current spend: $9,990
• We have 500,000 RPS globally
• 1000 requests for this advertiser arrive simultaneously
• Each bid is $20
If each server checks "is there budget?" independently:
• All 1000 see "$10 remaining"
• All 1000 approve the bid
• Actual spend: $9,990 + (1000 × $20) = $29,990
• OVERSPEND: $19,990 (200% over budget!)
This is a classic distributed consistency problem.
The Solution:
BUDGET ARCHITECTURE
We use a hierarchical budget allocation system:
┌───────────────────┐
│ GLOBAL BUDGET │
│ COORDINATOR │
│ (source of │
│ truth) │
└─────────┬─────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ US-EAST │ │ EU-WEST │ │ AP-SOUTH │
│ REGION BUDGET │ │ REGION BUDGET │ │ REGION BUDGET │
│ ALLOCATOR │ │ ALLOCATOR │ │ ALLOCATOR │
│ │ │ │ │ │
│ Allocation: │ │ Allocation: │ │ Allocation: │
│ $4,000 │ │ $3,500 │ │ $2,000 │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
┌───────┴───────┐ ┌───────┴───────┐ ┌───────┴───────┐
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐
│Server │ ... │Server │ ... │Server │ ...
│ Pod │ │ Pod │ │ Pod │
│ │ │ │ │ │
│Local: │ │Local: │ │Local: │
│ $100 │ │ $100 │ │ $100 │
└───────┘ └───────┘ └───────┘
HOW IT WORKS:
1. Global coordinator divides daily budget across regions
(Based on expected traffic distribution)
2. Region allocators divide among server pods
(Each pod gets a "budget lease")
3. Pods spend locally until lease exhausted
(No network call needed for each bid)
4. When lease low, request more from region allocator
(Background refresh, not in critical path)
5. If region exhausted, request rebalancing from global
(Shift unused budget from other regions)
You: "Let me show the implementation..."
# budget/distributed_budget.py
"""
Hierarchical budget management for real-time bidding.
Provides strong consistency guarantees while minimizing
latency impact on the critical bidding path.
"""
from dataclasses import dataclass
from typing import Dict, Optional, Tuple
from datetime import datetime, timedelta
import asyncio
import logging
logger = logging.getLogger(__name__)
@dataclass
class BudgetLease:
"""A local budget allocation."""
advertiser_id: str
campaign_id: str
allocated_amount: float
spent_amount: float
expires_at: datetime
@property
def remaining(self) -> float:
return self.allocated_amount - self.spent_amount
@property
def is_expired(self) -> bool:
return datetime.utcnow() > self.expires_at
@property
def utilization(self) -> float:
if self.allocated_amount == 0:
return 1.0
return self.spent_amount / self.allocated_amount
class LocalBudgetManager:
"""
Manages budget leases for a single server pod.
Design principles:
- Spend decisions are LOCAL (no network in hot path)
- Background refresh keeps leases topped up
- Conservative: rather reject bids than overspend
"""
def __init__(
self,
region_allocator,
pod_id: str,
refresh_threshold: float = 0.7, # Refresh at 70% utilization
lease_duration: timedelta = timedelta(seconds=30)
):
self.region = region_allocator
self.pod_id = pod_id
self.refresh_threshold = refresh_threshold
self.lease_duration = lease_duration
self.leases: Dict[str, BudgetLease] = {}
self._refresh_lock = asyncio.Lock()
async def can_spend(
self,
advertiser_id: str,
campaign_id: str,
amount: float
) -> Tuple[bool, str]:
"""
Check if we can spend amount. MUST BE FAST (<1ms).
Returns (can_spend, reason)
"""
key = f"{advertiser_id}:{campaign_id}"
lease = self.leases.get(key)
# No lease? Try to get one (but don't block hot path)
if lease is None:
# Trigger background refresh
asyncio.create_task(self._refresh_lease(advertiser_id, campaign_id))
return False, "no_budget_lease"
# Lease expired?
if lease.is_expired:
asyncio.create_task(self._refresh_lease(advertiser_id, campaign_id))
return False, "lease_expired"
# Not enough remaining?
if lease.remaining < amount:
asyncio.create_task(self._refresh_lease(advertiser_id, campaign_id))
return False, "insufficient_budget"
# Check if we need background refresh
if lease.utilization > self.refresh_threshold:
asyncio.create_task(self._refresh_lease(advertiser_id, campaign_id))
return True, "approved"
async def record_spend(
self,
advertiser_id: str,
campaign_id: str,
amount: float
) -> bool:
"""
Record spend against local lease.
Call this AFTER winning auction, BEFORE responding.
"""
key = f"{advertiser_id}:{campaign_id}"
lease = self.leases.get(key)
if lease is None or lease.remaining < amount:
# This shouldn't happen if can_spend was called
logger.warning(f"Spend rejected: {key}, amount={amount}")
return False
lease.spent_amount += amount
# Async report to region (for reconciliation)
asyncio.create_task(
self.region.report_spend(advertiser_id, campaign_id, amount)
)
return True
async def _refresh_lease(
self,
advertiser_id: str,
campaign_id: str
):
"""Background refresh of budget lease."""
key = f"{advertiser_id}:{campaign_id}"
async with self._refresh_lock:
try:
# Request new allocation from region
allocation = await self.region.request_allocation(
advertiser_id=advertiser_id,
campaign_id=campaign_id,
pod_id=self.pod_id,
requested_amount=self._calculate_request_amount(key)
)
if allocation.granted_amount > 0:
self.leases[key] = BudgetLease(
advertiser_id=advertiser_id,
campaign_id=campaign_id,
allocated_amount=allocation.granted_amount,
spent_amount=0,
expires_at=datetime.utcnow() + self.lease_duration
)
except Exception as e:
logger.error(f"Failed to refresh lease {key}: {e}")
class RegionBudgetAllocator:
"""
Manages budget allocation for a region.
Coordinates between:
- Global coordinator (gets region's share)
- Local pods (distributes to pods)
"""
def __init__(
self,
global_coordinator,
region_id: str,
redis_cluster
):
self.global_coord = global_coordinator
self.region_id = region_id
self.redis = redis_cluster
async def request_allocation(
self,
advertiser_id: str,
campaign_id: str,
pod_id: str,
requested_amount: float
) -> 'AllocationResult':
"""
Allocate budget to a pod.
Uses Redis for atomic operations within region.
"""
key = f"budget:{advertiser_id}:{campaign_id}:{self.region_id}"
# Lua script for atomic check-and-decrement
lua_script = """
local available = tonumber(redis.call('GET', KEYS[1]) or '0')
local requested = tonumber(ARGV[1])
if available <= 0 then
return 0
end
local granted = math.min(available, requested)
redis.call('DECRBY', KEYS[1], granted)
return granted
"""
granted = await self.redis.eval(
lua_script,
keys=[key],
args=[requested_amount]
)
if granted == 0:
# Try to get more from global
await self._request_global_refill(advertiser_id, campaign_id)
# Retry once
granted = await self.redis.eval(
lua_script,
keys=[key],
args=[requested_amount]
)
return AllocationResult(
granted_amount=granted,
advertiser_id=advertiser_id,
campaign_id=campaign_id
)
Interviewer: "Good. What happens during a region failure? How do you prevent double-spending?"
You: "Great question. We use budget reservations with expiration..."
FAILURE HANDLING
Scenario: US-EAST region goes down
1. IMMEDIATE
• Region had $4,000 allocated
• That budget is "locked" (not available to other regions)
• Global coordinator detects failure (health check fails)
2. AFTER 30 SECONDS (lease expiration)
• All pod leases expire
• Region's allocation returned to global pool
• Other regions can now claim it
3. RECONCILIATION
• When US-EAST recovers
• Reports actual spend from before failure
• Kafka events provide source of truth
• Any discrepancy flagged for review
WHY THIS IS SAFE:
• Worst case: We UNDER-spend during failure (region can't bid)
• Never over-spend (leases expire, budget returns)
• Accept temporary reduced efficiency over correctness violation
Deep Dive 2: DSP Fan-Out with Timeouts
Week 2 concepts: Timeouts, circuit breakers, failure handling.
You: "The DSP fan-out is where we battle latency. Let me show how we handle partial failures gracefully."
# bidding/dsp_gateway.py
"""
DSP Gateway: Manages communication with demand-side platforms.
Challenges:
- Must query 5-10 DSPs in parallel
- Each DSP has different latency characteristics
- Total budget: 70ms (must leave margin for auction)
- Partial responses are OK (bid with what we have)
"""
from dataclasses import dataclass, field
from typing import List, Dict, Optional, Set
from datetime import datetime
import asyncio
import logging
logger = logging.getLogger(__name__)
@dataclass
class DSPConfig:
"""Configuration for a DSP."""
dsp_id: str
endpoint: str
timeout_ms: int = 70
# Circuit breaker settings
failure_threshold: int = 5 # Failures before opening
success_threshold: int = 3 # Successes before closing
half_open_timeout_s: int = 30 # Time before retrying
# Performance tracking
p99_latency_ms: float = 50
error_rate: float = 0.01
@dataclass
class DSPBid:
"""A bid from a DSP."""
dsp_id: str
bid_id: str
price: float
ad_markup: str
latency_ms: float
received_at: datetime
@dataclass
class FanOutResult:
"""Results from DSP fan-out."""
bids: List[DSPBid]
timeouts: List[str] # DSP IDs that timed out
errors: List[str] # DSP IDs that errored
circuit_open: List[str] # DSP IDs with open circuits
total_latency_ms: float
class CircuitBreaker:
"""
Circuit breaker for a single DSP.
States:
- CLOSED: Normal operation, requests flow through
- OPEN: DSP is unhealthy, fail fast (don't even try)
- HALF_OPEN: Testing if DSP recovered
"""
def __init__(self, config: DSPConfig):
self.config = config
self.state = "CLOSED"
self.failure_count = 0
self.success_count = 0
self.last_failure_time: Optional[datetime] = None
def can_execute(self) -> bool:
if self.state == "CLOSED":
return True
if self.state == "OPEN":
# Check if we should try half-open
if self.last_failure_time:
elapsed = (datetime.utcnow() - self.last_failure_time).total_seconds()
if elapsed > self.config.half_open_timeout_s:
self.state = "HALF_OPEN"
return True
return False
if self.state == "HALF_OPEN":
return True
return False
def record_success(self):
if self.state == "HALF_OPEN":
self.success_count += 1
if self.success_count >= self.config.success_threshold:
self.state = "CLOSED"
self.failure_count = 0
self.success_count = 0
else:
self.failure_count = 0
def record_failure(self):
self.failure_count += 1
self.last_failure_time = datetime.utcnow()
if self.state == "HALF_OPEN":
self.state = "OPEN"
self.success_count = 0
elif self.failure_count >= self.config.failure_threshold:
self.state = "OPEN"
class DSPGateway:
"""
Gateway for querying DSPs with timeout and failure handling.
"""
def __init__(
self,
http_client,
dsp_configs: List[DSPConfig],
global_timeout_ms: int = 70
):
self.http = http_client
self.dsps = {cfg.dsp_id: cfg for cfg in dsp_configs}
self.global_timeout_ms = global_timeout_ms
# Circuit breakers per DSP
self.breakers = {
cfg.dsp_id: CircuitBreaker(cfg)
for cfg in dsp_configs
}
# Metrics
self.metrics = DSPMetrics()
async def fan_out(
self,
request: 'BidRequest',
target_dsps: List[str]
) -> FanOutResult:
"""
Query multiple DSPs in parallel with timeout.
Key design decisions:
1. Start all requests immediately (parallel)
2. Use global timeout (not per-DSP)
3. Collect responses as they arrive
4. Return whatever we have when timeout hits
"""
start_time = datetime.utcnow()
result = FanOutResult(
bids=[],
timeouts=[],
errors=[],
circuit_open=[],
total_latency_ms=0
)
# Filter out DSPs with open circuits
active_dsps = []
for dsp_id in target_dsps:
breaker = self.breakers.get(dsp_id)
if breaker and breaker.can_execute():
active_dsps.append(dsp_id)
else:
result.circuit_open.append(dsp_id)
if not active_dsps:
return result
# Create tasks for all DSPs
tasks = {
dsp_id: asyncio.create_task(
self._query_dsp(dsp_id, request)
)
for dsp_id in active_dsps
}
# Wait with timeout, collecting results as they arrive
pending = set(tasks.values())
deadline = self.global_timeout_ms / 1000
try:
while pending:
# Calculate remaining time
elapsed = (datetime.utcnow() - start_time).total_seconds()
remaining = deadline - elapsed
if remaining <= 0:
# Timeout! Cancel remaining and break
for task in pending:
task.cancel()
break
# Wait for next completion or timeout
done, pending = await asyncio.wait(
pending,
timeout=remaining,
return_when=asyncio.FIRST_COMPLETED
)
# Process completed tasks
for task in done:
dsp_id = self._get_dsp_id_for_task(task, tasks)
try:
bid = task.result()
if bid:
result.bids.append(bid)
self.breakers[dsp_id].record_success()
except asyncio.TimeoutError:
result.timeouts.append(dsp_id)
self.breakers[dsp_id].record_failure()
except Exception as e:
result.errors.append(dsp_id)
self.breakers[dsp_id].record_failure()
logger.warning(f"DSP {dsp_id} error: {e}")
finally:
# Cancel any still pending
for task in pending:
task.cancel()
dsp_id = self._get_dsp_id_for_task(task, tasks)
result.timeouts.append(dsp_id)
result.total_latency_ms = (
datetime.utcnow() - start_time
).total_seconds() * 1000
# Log metrics
self.metrics.record_fanout(result)
return result
async def _query_dsp(
self,
dsp_id: str,
request: 'BidRequest'
) -> Optional[DSPBid]:
"""Query a single DSP."""
config = self.dsps[dsp_id]
start = datetime.utcnow()
try:
response = await self.http.post(
config.endpoint,
json=request.to_dsp_format(),
timeout=config.timeout_ms / 1000
)
latency = (datetime.utcnow() - start).total_seconds() * 1000
if response.status == 204:
# No bid
return None
bid_data = response.json()
return DSPBid(
dsp_id=dsp_id,
bid_id=bid_data['id'],
price=bid_data['price'],
ad_markup=bid_data['adm'],
latency_ms=latency,
received_at=datetime.utcnow()
)
except asyncio.TimeoutError:
raise
except Exception as e:
logger.error(f"DSP {dsp_id} request failed: {e}")
raise
Interviewer: "What if all DSPs are slow one day? How do you prevent cascading failures?"
You: "We implement backpressure at the edge. If we're falling behind, we shed load gracefully..."
BACKPRESSURE AND LOAD SHEDDING
When system is overwhelmed:
1. DETECT OVERLOAD
• Request queue depth > threshold
• p99 latency > 80ms (approaching limit)
• CPU utilization > 80%
2. SHED LOAD GRACEFULLY
• Return "no bid" immediately for low-value requests
• Prioritize high-value ad slots
• Random shedding to be fair across publishers
3. ADAPTIVE TIMEOUT
• If we're fast, use full 70ms
• If we're slow, reduce to 50ms (faster failures = more capacity)
4. DSP PRIORITIZATION
• During overload, only query top 3 DSPs (by historical performance)
• Skip consistently slow DSPs
This is Week 3's backpressure pattern applied to real-time bidding!
Deep Dive 3: Audit Trail at Scale
Week 3 concepts: Event streaming, transactional outbox. Week 8 concepts: Analytics pipeline.
You: "Every bid request must be logged for billing and compliance. That's 10 billion events per day. Let me show the pipeline."
AUDIT TRAIL ARCHITECTURE
Requirements:
• Every event captured (no loss)
• Ordered per advertiser (for billing accuracy)
• 7-year retention
• Queryable for disputes
CRITICAL PATH
(sync, ~5ms)
│
┌─────────────────────────────────────┼───────────────────────────────┐
│ │ │
│ Bid Orchestrator ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 1. Process request │ │
│ │ 2. Run auction │ │
│ │ 3. Write to OUTBOX TABLE (same transaction as budget) │ │
│ │ 4. Return response │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
└─────────────────────────────────────┼───────────────────────────────┘
│
│ (Transactional Outbox Pattern)
│
ASYNC PATH
(background)
│
┌─────────────────────────────────────┼───────────────────────────────┐
│ ▼ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Outbox Poller │───▶│ Kafka │ │
│ │ (Debezium CDC) │ │ bid-events │ │
│ └──────────────────┘ │ partitioned by │ │
│ │ advertiser_id │ │
│ └────────┬─────────┘ │
│ │ │
│ ┌───────────────────────┼───────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Billing │ │ Analytics │ │ Fraud ML │ │
│ │ Consumer │ │ Consumer │ │ Training │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Billing │ │ S3 │ │ Feature │ │
│ │ Database │ │ Data Lake │ │ Store │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Glacier │ │
│ │ (7 years) │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
# audit/event_pipeline.py
"""
Audit event schema and processing.
Every bid event follows this schema for consistency
across billing, analytics, and compliance.
"""
from dataclasses import dataclass, asdict
from typing import List, Dict, Optional, Any
from datetime import datetime
import json
@dataclass
class BidEvent:
"""
Immutable record of a bid transaction.
This is the source of truth for:
- Billing reconciliation
- Analytics dashboards
- Fraud investigation
- Compliance audits
"""
# Identity
event_id: str # UUID, globally unique
event_type: str # "bid_request", "bid_response", "auction_result"
event_time: datetime # When this happened (event time, not processing time)
# Request context
request_id: str # Correlates all events for one request
exchange_id: str # Which ad exchange
publisher_id: str # Which publisher
# Advertiser context
advertiser_id: str # For partitioning and billing
campaign_id: str
# Auction details
bid_price: Optional[float] = None
win_price: Optional[float] = None # Second price (what they actually pay)
is_winner: bool = False
# DSP details
dsp_id: Optional[str] = None
dsp_latency_ms: Optional[float] = None
# User context (privacy-compliant)
user_id_hash: Optional[str] = None # Hashed, not raw
geo_country: Optional[str] = None
device_type: Optional[str] = None
# Technical metadata
region: str = ""
pod_id: str = ""
processing_time_ms: float = 0
def to_json(self) -> str:
"""Serialize for Kafka."""
data = asdict(self)
data['event_time'] = self.event_time.isoformat()
return json.dumps(data)
@property
def partition_key(self) -> str:
"""Kafka partition key ensures ordering per advertiser."""
return self.advertiser_id
# Kafka topic configuration
KAFKA_TOPIC_CONFIG = {
'name': 'bid-events',
'partitions': 256, # High partition count for parallelism
'replication_factor': 3, # Durability
'retention_ms': 7 * 24 * 60 * 60 * 1000, # 7 days hot
'cleanup_policy': 'delete',
# Compaction settings for efficiency
'compression_type': 'zstd', # Best compression ratio
'max_message_bytes': 1048576, # 1MB max
}
Interviewer: "7 years of data at 10 billion events/day. How do you make that queryable for billing disputes?"
You: "Tiered storage with intelligent partitioning..."
DATA TIERING STRATEGY
HOT TIER (0-7 days): Kafka + Elasticsearch
• Fast queries for recent data
• Used for real-time dashboards
• ~560 billion events
WARM TIER (7-90 days): S3 Parquet + Presto
• Columnar format for analytical queries
• Partitioned by date + advertiser_id
• ~2.5 trillion events
COLD TIER (90 days - 7 years): S3 Glacier
• Compressed archives
• Queryable with Athena (slower)
• Restored on-demand for disputes
• ~25+ trillion events
QUERY ROUTING:
• "Last 24 hours" → Elasticsearch (sub-second)
• "Last month" → Presto on S3 (seconds)
• "2 years ago" → Glacier restore + Athena (minutes-hours)
Deep Dive 4: Fraud Detection in Real-Time
Week 9 concepts: Security, ML inference at scale.
You: "We need to detect and block invalid traffic in the critical path, without adding latency."
FRAUD DETECTION ARCHITECTURE
The challenge:
• Must decide in <5ms (part of edge processing budget)
• 500K RPS of inference
• Accuracy matters (false positives = lost revenue)
SOLUTION: Tiered Detection
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ TIER 1: RULE-BASED BLOCKING (<0.5ms) │
│ ───────────────────────────────────── │
│ • Known bad IPs (blocklist) │
│ • Known data center ranges │
│ • Rate limiting per IP/user │
│ • Impossible geography (user in 2 countries in 1 second) │
│ │
│ Blocks: ~5% of traffic (obvious bots) │
│ │
│ ═══════════════════════════════════════════════════════════════════ │
│ │
│ TIER 2: ML SCORING (<2ms) │
│ ───────────────────────── │
│ • Pre-computed features (cached in Redis) │
│ • Lightweight model (gradient boosting) │
│ • Returns fraud probability (0-1) │
│ │
│ High confidence fraud (>0.95): Block │
│ Medium confidence (0.5-0.95): Flag, bid lower │
│ Low confidence (<0.5): Allow │
│ │
│ Blocks: ~2% of traffic │
│ │
│ ═══════════════════════════════════════════════════════════════════ │
│ │
│ TIER 3: ASYNC DEEP ANALYSIS (non-blocking) │
│ ─────────────────────────────────────────── │
│ • Complex neural network │
│ • Analyzes patterns over time │
│ • Updates blocklists and ML model features │
│ • Runs on event stream (not real-time path) │
│ │
│ Identifies: Sophisticated attacks, click farms, etc. │
│ │
└────────────────────────────────────────────────────────────────────────┘
# fraud/realtime_detector.py
"""
Real-time fraud detection in the bidding pipeline.
Constraint: Must complete in <5ms including all tiers.
"""
from dataclasses import dataclass
from typing import Tuple
import numpy as np
@dataclass
class FraudSignals:
"""Features extracted for fraud detection."""
ip_address: str
user_agent: str
device_id: str
geo_country: str
request_rate_1m: int # Requests from this IP in last minute
request_rate_1h: int # Requests from this IP in last hour
user_age_days: int # How long we've seen this user
session_duration: float # Current session length
click_rate: float # Historical click-through rate
class RealTimeFraudDetector:
"""
Tiered fraud detection for real-time bidding.
"""
def __init__(
self,
blocklist_store,
feature_store,
ml_model,
rate_limiter
):
self.blocklist = blocklist_store # Redis set
self.features = feature_store # Redis hash
self.model = ml_model # Pre-loaded XGBoost
self.limiter = rate_limiter
async def evaluate(
self,
signals: FraudSignals
) -> Tuple[str, float]:
"""
Evaluate fraud risk.
Returns: (decision, confidence)
- decision: "block", "flag", "allow"
- confidence: 0.0 to 1.0
"""
# TIER 1: Rule-based checks (<0.5ms)
tier1_result = await self._tier1_rules(signals)
if tier1_result == "block":
return "block", 0.99
# TIER 2: ML scoring (<2ms)
fraud_score = await self._tier2_ml_score(signals)
if fraud_score > 0.95:
return "block", fraud_score
elif fraud_score > 0.5:
return "flag", fraud_score
else:
return "allow", 1 - fraud_score
async def _tier1_rules(self, signals: FraudSignals) -> str:
"""
Fast rule-based checks.
Rules are simple, but catch obvious fraud instantly.
"""
# Check IP blocklist
if await self.blocklist.contains(signals.ip_address):
return "block"
# Check rate limits
if signals.request_rate_1m > 100: # >100 requests/minute from one IP
return "block"
# Check for data center IP ranges
if self._is_datacenter_ip(signals.ip_address):
return "block"
return "allow"
async def _tier2_ml_score(self, signals: FraudSignals) -> float:
"""
ML-based fraud scoring.
Uses pre-computed features and lightweight model.
"""
# Get historical features from Redis
historical = await self.features.get(signals.device_id)
# Build feature vector
features = np.array([
signals.request_rate_1m,
signals.request_rate_1h,
signals.user_age_days,
signals.session_duration,
signals.click_rate,
historical.get('conversion_rate', 0),
historical.get('avg_session_length', 0),
historical.get('fraud_score_history', 0),
])
# Score with pre-loaded model (XGBoost inference is fast)
score = self.model.predict_proba(features.reshape(1, -1))[0][1]
return score
Phase 5: Scaling and Edge Cases
Interviewer: "Impressive coverage. Now let's stress test your design. What happens during the Super Bowl when traffic goes 5x?"
You: "We handle this with predictive scaling and graceful degradation..."
Super Bowl Scale Event
HANDLING 5X TRAFFIC SPIKE
BEFORE THE EVENT (24 hours prior):
• Pre-scale all regions to 3x capacity
• Warm up caches with likely ad content
• Alert on-call team
• Verify runbooks
DURING THE EVENT:
• Auto-scaling handles 3x → 5x if needed
• DSP fan-out reduced (query top 5 only, not 10)
• Longer latency tolerance (relax to 120ms if needed)
• Non-critical features disabled (detailed logging reduced)
IF WE'RE STILL OVERWHELMED:
• Load shedding kicks in
• Lower-value requests get "no bid" response
• High-value requests prioritized
• Status page updated if significant
METRICS TO WATCH:
• Request queue depth
• p99 latency (should stay <100ms)
• Budget accuracy (must stay correct)
• Revenue per second (business metric)
Edge Cases
You: "Let me walk through critical edge cases..."
EDGE CASE 1: DSP Goes Rogue (Returns in 500ms)
Problem: One DSP starts responding very slowly
Impact: Slows down all auctions that include them
Solution:
• Circuit breaker opens after 5 consecutive timeouts
• DSP excluded from future requests for 30s
• Automatic recovery when they improve
• Alert fires for ops awareness
EDGE CASE 2: Clock Skew Between Regions
Problem: Different regions see different "now"
Impact: Budget leases might overlap or gap
Solution:
• Use logical time (lamport clocks) for critical operations
• NTP synchronization on all servers
• Lease expiration has buffer (30s lease, 25s working time)
• Daily reconciliation catches any drift
EDGE CASE 3: Network Partition Between Regions
Problem: US-EAST can't talk to global coordinator
Impact: Can't refresh budget allocations
Solution:
• Each region operates independently during partition
• Conservative: Stop bidding when lease expires
• Partition detection via gossip protocol
• Automatic recovery when connectivity restored
EDGE CASE 4: Flash Crash of DSP Responses
Problem: All DSPs suddenly return no bids
Impact: No ads to serve, revenue drops
Detection:
• Sudden drop in bid rate (compared to baseline)
• All DSPs affected vs one DSP affected
Response:
• If one DSP: circuit breaker handles it
• If all DSPs: alert, may be exchange issue
• Fallback: serve house ads if configured
Phase 6: Monitoring and Operations
You: "Let me define the SLOs and observability strategy for this system..."
SLOs and SLIs
SERVICE LEVEL OBJECTIVES
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ SLO 1: LATENCY │
│ ─────────────── │
│ SLI: Percentage of requests completing within 100ms │
│ Target: 99.9% of requests < 100ms │
│ Measurement: Histogram of response times at load balancer │
│ │
│ Error Budget: 0.1% of requests can exceed 100ms │
│ Per day at 10B requests: 10 million slow requests allowed │
│ │
│ ──────────────────────────────────────────────────────────────────── │
│ │
│ SLO 2: AVAILABILITY │
│ ─────────────────── │
│ SLI: Percentage of requests that receive valid response │
│ Target: 99.99% availability │
│ Measurement: (Successful responses) / (Total requests) │
│ │
│ Error Budget: 0.01% requests can fail │
│ Per day at 10B requests: 1 million failures allowed │
│ │
│ ──────────────────────────────────────────────────────────────────── │
│ │
│ SLO 3: BUDGET ACCURACY │
│ ────────────────────── │
│ SLI: Percentage of campaigns within 0.1% of budget │
│ Target: 99.9% of campaigns never exceed budget by >0.1% │
│ Measurement: (Actual spend - Budget) / Budget │
│ │
│ This is a HARD requirement (contractual obligation) │
│ │
│ ──────────────────────────────────────────────────────────────────── │
│ │
│ SLO 4: BID RATE │
│ ──────────────── │
│ SLI: Percentage of requests where we submit a bid │
│ Target: >80% bid rate (when we have budget) │
│ Measurement: (Bids submitted) / (Requests with budget) │
│ │
│ Lower bid rate = lost revenue opportunity │
│ │
└────────────────────────────────────────────────────────────────────────┘
Key Dashboards
OPERATIONAL DASHBOARDS
DASHBOARD 1: REAL-TIME BIDDING HEALTH
├── Requests per second (by region)
├── Bid rate (should be >80%)
├── Latency p50/p99 (should be <100ms)
├── Error rate (should be <0.01%)
├── DSP response times (per DSP)
└── Circuit breaker states
DASHBOARD 2: BUSINESS METRICS
├── Revenue per second
├── Spend rate (vs budget)
├── Win rate (bids won / bids submitted)
├── Average win price
└── Top advertisers by spend
DASHBOARD 3: FRAUD OVERVIEW
├── Block rate (Tier 1 rules)
├── Flag rate (Tier 2 ML)
├── False positive estimates
├── Top blocked IPs/patterns
└── Model drift indicators
DASHBOARD 4: INFRASTRUCTURE
├── CPU/Memory utilization by service
├── Kafka lag (should be near zero)
├── Redis memory usage
├── Database connection pool status
└── Regional traffic distribution
Interview Conclusion
Interviewer: "This has been an exceptional session. You've demonstrated deep understanding across all dimensions — from low-level latency optimization to high-level architectural decisions. A few rapid-fire questions:"
Interviewer: "Why not use gRPC instead of HTTP for DSP communication?"
You: "Good question. gRPC would give us better performance with HTTP/2 multiplexing and protobuf serialization. The trade-off is that DSPs would need to support gRPC, which many don't. For the DSPs we control, we could use gRPC internally. For external DSPs, we'd use HTTP with connection pooling and keep-alive."
Interviewer: "If you had to cut latency from 100ms to 50ms, where would you start?"
You: "I'd focus on the DSP fan-out since that's 70ms of our budget. Options:
- Reduce DSP count from 10 to 5 (fewer bids but faster)
- Use predictive models to guess which DSPs will bid (skip unlikely ones)
- Tighter timeouts (50ms instead of 70ms)
- Edge caching of DSP bid models for popular requests"
Interviewer: "What's the biggest risk in this system?"
You: "Budget accuracy. Unlike latency or availability where degradation is bad but recoverable, budget violations are contractual breaches. If we overspend, advertisers don't pay — we eat the cost. I'd invest heavily in testing the budget system, including chaos engineering specifically for the budget path."
Interviewer: "Excellent. Any questions for me?"
You: "Yes — at your actual scale, what was the hardest problem to solve? And how do you handle the cold start problem for new advertisers with no historical data for fraud detection?"
The interviewer smiles.
Interviewer: "Great questions — and exactly what I'd expect from a senior candidate. Welcome to the team."
Summary: Ten Weeks of Learning Applied
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ CONCEPTS APPLIED IN THIS DESIGN │
│ │
│ WEEK 1: DATA AT SCALE │
│ ├── Partitioning: Budget by advertiser, events by advertiser │
│ ├── Replication: Multi-region for availability │
│ └── Consistency: Strong for budget, eventual for analytics │
│ │
│ WEEK 2: FAILURE-FIRST DESIGN │
│ ├── Timeouts: 70ms DSP timeout with budget for auction │
│ ├── Circuit breakers: Per-DSP failure isolation │
│ └── Idempotency: Event IDs for exactly-once processing │
│ │
│ WEEK 3: MESSAGING & ASYNC │
│ ├── Transactional outbox: Guaranteed event capture │
│ ├── Kafka: Event streaming for audit trail │
│ └── Backpressure: Load shedding during overload │
│ │
│ WEEK 4: CACHING │
│ ├── User data caching: Redis for enrichment │
│ ├── DSP response caching: Where appropriate │
│ └── Feature caching: For real-time ML inference │
│ │
│ WEEK 5: CONSISTENCY & COORDINATION │
│ ├── Distributed budget: Hierarchical allocation │
│ ├── Lease-based consistency: Local spending with global truth │
│ └── Conflict resolution: Conservative (under-spend > over-spend) │
│ │
│ WEEK 6: NOTIFICATION PLATFORM │
│ ├── Multi-channel delivery: Applied to DSP fan-out │
│ ├── Priority queuing: High-value requests first │
│ └── Dead letter handling: Failed DSP requests tracked │
│ │
│ WEEK 7: SEARCH SYSTEM │
│ ├── Indexing: Not directly, but similar patterns for user lookup │
│ └── Query optimization: Fast feature lookup for ML │
│ │
│ WEEK 8: ANALYTICS PIPELINE │
│ ├── Event ingestion: 10B events/day capture │
│ ├── Tiered storage: Hot/warm/cold for 7-year retention │
│ └── Late arriving data: Reconciliation processes │
│ │
│ WEEK 9: MULTI-TENANCY & SECURITY │
│ ├── Tenant isolation: Per-advertiser budget isolation │
│ ├── Fraud detection: ML-based traffic validation │
│ └── Audit compliance: Complete transaction history │
│ │
│ WEEK 10: PRODUCTION READINESS │
│ ├── SLOs: Latency, availability, budget accuracy │
│ ├── Observability: Metrics, logs, traces for debugging │
│ ├── Deployment: Canary with automatic rollback │
│ ├── Capacity: Predictive scaling for events │
│ └── Incidents: Runbooks for common failure modes │
│ │
└────────────────────────────────────────────────────────────────────────┘
Self-Assessment Checklist
After studying this capstone, you should be able to:
Requirements & Estimation:
- Clarify requirements before designing
- Calculate traffic, storage, and infrastructure needs
- Create latency budgets for time-sensitive systems
Architecture:
- Design multi-region systems for global availability
- Create appropriate separation of concerns
- Handle real-time and batch processing in one system
Distributed Systems:
- Implement strong consistency where required (budget)
- Use eventual consistency appropriately (analytics)
- Design hierarchical systems for coordination at scale
Performance:
- Optimize for latency-critical paths
- Implement parallel processing with timeouts
- Use caching effectively at multiple layers
Reliability:
- Implement circuit breakers and bulkheads
- Design for graceful degradation
- Handle edge cases and failure modes
Operations:
- Define meaningful SLOs
- Design observability into the system
- Plan for capacity and scaling events
- Create runbooks for incident response
🎓 Congratulations!
╔═════════════════════════════════════════════════════════════════════════╗
║ ║
║ SYSTEM DESIGN MASTERY COMPLETE ║
║ ║
║ 10 Weeks ║
║ 50 Lessons ║
║ 10 Capstones ║
║ 1 Complete Toolkit ║
║ ║
║ ════════════════════════════════════════════════════════════════════ ║
║ ║
║ You've learned to: ║
║ ║
║ ✓ Design systems that scale to millions of users ║
║ ✓ Build for failure from the start ║
║ ✓ Make informed trade-offs between consistency and availability ║
║ ✓ Implement production-ready patterns ║
║ ✓ Operate systems with confidence ║
║ ✓ Communicate designs clearly in interviews ║
║ ║
║ ════════════════════════════════════════════════════════════════════ ║
║ ║
║ Remember: ║
║ ║
║ "The goal isn't to memorize solutions — ║
║ it's to build intuition for trade-offs. ║
║ ║
║ When someone asks 'how would you design X?', ║
║ your first instinct should be: ║
║ 'What are the constraints? What can we sacrifice?' ║
║ ║
║ That's senior engineering thinking." ║
║ ║
║ ════════════════════════════════════════════════════════════════════ ║
║ ║
║ Go build something great. ║
║ ║
╚═════════════════════════════════════════════════════════════════════════╝
End of Week 10 Capstone
End of System Design Mastery: 10-Week Intensive Program