Week 12 — Capstone Design Session

The 45-Minute Design Framework

Memorise this structure. Use it every time.

0–5 min    Clarify requirements
5–15 min   High-level design
15–30 min  Deep dive (2 components)
30–40 min  Bottlenecks & failures
40–45 min  Trade-offs

Phase 1 — Clarify (0–5 min)

Never start drawing until you know:

• Users: how many? where? what are they doing?
• Scale: req/sec, data volume, growth rate
• Features: what’s in scope? what’s explicitly out?
• Constraints: latency SLA, consistency requirements, budget?

Ask, don’t assume. Interviewers deliberately leave these ambiguous.

Phase 2 — High-Level Design (5–15 min)

Boxes and arrows. Happy path only. No details yet.

Client → CDN → Load Balancer → App Servers → Cache (Redis)
                                            → Primary DB
                                            → Message Queue → Workers

Confirm the approach before going deeper.

Phase 3 — Deep Dive (15–30 min)

Pick the 2 hardest components. Go deep on each.

For a URL shortener: short code generation + redirect caching. For a chat system: message delivery guarantees + presence.

Show you know the trade-offs, not just the happy path.

Phase 4 — Bottlenecks (30–40 min)

• What’s the first thing that breaks at 10x load?
• What are the single points of failure?
• What’s your disaster recovery plan?

Phase 5 — Trade-offs (40–45 min)

• What did you sacrifice for what gain?
• What would you do differently with 10x the budget?
• What would you change if the consistency requirement changed?

---

Capstone Problem 1 — URL Shortener

Requirements: create short URLs, 100M URLs total, 10B redirects/day

Scale: 10B/day = ~116K req/sec at peak

Architecture:

Write: Client → API → App → PostgreSQL (url + short_code)
Read:  Client → CDN cache → Redis → PostgreSQL (fallback)

Short code generation: base62 encode a 64-bit ID (a-z, A-Z, 0-9). 7 chars = 62^7 = 3.5 trillion unique codes.

Key decisions:

• Use 301 (permanent) redirect for SEO, 302 for analytics tracking
• Pre-generate short codes in batches to avoid hotspot on ID generator
• Cache hot URLs in Redis with LRU — most redirects hit a small set of URLs

---

Capstone Problem 2 — Multi-Tenant SaaS ERP

Requirements: host 10,000 companies on shared infrastructure, each isolated

Architecture:

Tenant request → Router (reads tenant → DB mapping) → DB cluster

Database strategy:

• 1 PostgreSQL instance per 50–100 tenants (database-per-tenant)
• Tenant registry in a central metadata DB: { tenant_id, db_host, db_name }
• New tenant provisioning: copy template DB → create schema → configure

Bin-packing: assign new tenants to instances with spare capacity. Track storage + CPU per tenant.

Backup: per-database backups for isolated recovery (not instance-level — restoring one tenant shouldn’t affect others).

Key decisions:

• Schema-per-tenant (shared DB) vs database-per-tenant: database-per-tenant wins for isolation and easy migration
• Regional deployment: tenants assigned to region closest to them, data residency compliance

---

Reference Card

Latency

Operation	Time
L1 cache	~1 ns
RAM	~100 ns
SSD	~100 µs
Same-DC network	~500 µs
Cross-continent	~150 ms

Technology Selection

Need	Tool
Session / hot cache	Redis
Full-text search	Elasticsearch
Event streaming	Kafka
ACID transactions	PostgreSQL
Object storage	S3-compatible
Async jobs	RabbitMQ / Celery

Key Acronyms

Term	Stands for
CAP	Consistency, Availability, Partition tolerance
ACID	Atomicity, Consistency, Isolation, Durability
RPO	Recovery Point Objective (max data loss)
RTO	Recovery Time Objective (max downtime)
SLO	Service Level Objective
SLA	Service Level Agreement
CQRS	Command Query Responsibility Segregation