Apply the 4-step blueprint to real-world systems. Each study includes requirements, scale estimates, architecture, and key trade-offs.
1. URL Shortener (e.g., TinyURL, bit.ly)
Requirements: Generate short aliases for long URLs; redirect to original URL on visit; track click count; optional expiration.
Scale: 100M URLs/month, 1B redirects/month, read-heavy (10:1 read-to-write).
Key Design Decisions:
Encoding: Base62 (a-z, A-Z, 0-9) for short keys. 7 characters → 62^7 ≈ 3.5 trillion combinations.
Key generation: Use a distributed ID generator (Snowflake) or pre-generate keys in a pool to avoid collisions.
Storage: SQL database (PostgreSQL) for strong consistency on key uniqueness. Cache in Redis for hot URLs.
Redirect: 301 (permanent) for SEO, 302 (temporary) for analytics — use 301 but count clicks before redirect.
# API Design
POST /shorten { "url": "https://example.com/very-long-url" }
Response: { "short_url": "https://short.ly/Ab3X9zQ" }
GET /Ab3X9zQ → HTTP 301 redirect to original URL
2. Ticketing System (e.g., BookMyShow, Ticketmaster)
Requirements: Browse events, select seats, reserve and pay within a time window, handle concurrent booking (no double booking).
Challenges: Race conditions on seat selection, payment failures after reservation, high traffic on popular events.
Key Design Decisions:
Pessimistic locking: Lock seats during checkout (row-level lock in SQL).
Reservation TTL: Reserve seats for 10 minutes; release if payment not completed.
Queue: Use a queue to manage burst traffic for popular events. Show users a "waiting room" page.
Idempotent payments: Prevent double-charging with idempotency keys.
3. News Feed (e.g., Facebook, Twitter, LinkedIn)
Requirements: Users see posts from followed accounts, ordered by recency/relevance, support infinite scroll, low latency (~500ms).
Approaches:
Fan-out on write (push): When a user posts, push the post to all followers' timelines. Good for users with few followers.
Fan-out on read (pull): When a user opens their feed, fetch posts from followed users. Good for celebrities with millions of followers.
Hybrid: Push to active followers, pull for inactive. Fan-out through a queue (Kafka).
# Hybrid feed approach
When user A posts:
For followers with timeline in cache:
Push post to each follower's timeline list (Redis sorted set, score=timestamp)
For inactive followers / celebrities:
Store post in A's timeline; followers pull on login
4. Notification System
Requirements: Send push notifications, emails, and SMS to millions of users. Support multiple channels, delivery tracking, rate limiting.
Architecture:
Notification service: Accepts notification requests, stores in DB, enqueues to channel-specific queues.
Rate limiter: Per-user, per-channel, per-minute limits. Avoid being flagged as spam.
Template engine: Render notifications from templates (e.g., "Your order {order_id} has shipped").
Delivery workers: Consume from queues, send via FCM (push), SendGrid (email), Twilio (SMS).
Dead letter queue: Failed notifications (invalid device token, bounced email) stored for retry/inspection.
5. Chat Application (e.g., WhatsApp, Messenger)
Requirements: Real-time messaging, group chats, message delivery status (sent/delivered/read), offline messages, media sharing.
Key Design Decisions:
WebSocket: Persistent connection for real-time message delivery.
Message store: Cassandra or similar for high-write throughput. Partition by conversation_id.
Message ordering: Use logical clocks or server-assigned sequence numbers per conversation.
Offline delivery: Store messages in DB; deliver via push notification when user is offline.
End-to-end encryption: Signal protocol for E2E encryption (optional but increasingly expected).
6. Auction Platform (e.g., eBay)
Requirements: List items, place bids, auto-bidding, auction countdown, outbid notifications.
Challenges: Last-second bidding (sniping), concurrent bids on the same item, real-time countdown accuracy.
Key Decisions:
Auto-bidding: Server maintains a maximum bid per user and automatically increments until max is reached.
Sniping mitigation: Extend auction by 1 minute if a bid is placed in the last 30 seconds.
Consistency: Use optimistic locking (version column) on the bid record to prevent double bids.
7. Rental Platform (e.g., Airbnb)
Requirements: List properties, search with filters (dates, location, price, amenities), booking calendar, reviews, payments.
Key Challenges: Calendar availability (complex date overlap queries), search with geo-indexing, review moderation.
Search: Elasticsearch for text + geo queries. Index properties with availability dates.
Calendar: Store each booked night as a separate row for simple overlap queries, or use PostgreSQL's daterange with exclusion constraints.
Pricing engine: Dynamic pricing based on demand, seasonality, events. Run as a background job (hourly).
8. Cloud Storage (e.g., Google Drive, Dropbox)
Requirements: Upload/download files, sync across devices, file versioning, sharing with permissions, conflict resolution.
Architecture:
File chunking: Split files into fixed-size chunks (e.g., 4MB). Deduplicate identical chunks across users.
Delta sync: Only upload changed chunks, not the entire file.
Metadata DB: SQL database for file metadata, folder hierarchy, permissions.
Object storage: S3 for raw chunks. Versioning via S3 versioning or separate chunk tables.
Conflict resolution: CRDTs (Conflict-Free Replicated Data Types) or last-writer-wins with version history.
# File sync flow
User saves file → Client diffs chunks
Upload changed chunks to object storage
Update metadata DB: "file_id=42, version=5, chunk_list=[...]"
Notify other devices: "File X updated to v5"
Other devices download changed chunks and merge
9. Video Sharing (e.g., YouTube)
Requirements: Upload videos (up to 4K, multi-GB), transcoding to multiple resolutions, streaming with adaptive bitrate, search, recommendations, comments.
Product service: Catalog, categories, variants (size/color). Elasticsearch for search.
Cart service: In-memory (Redis) with write-back to DB. Handles merge of guest → logged-in cart.
Order service: Orchestrates checkout flow. Create order → reserve inventory → process payment → confirm.
Inventory service: Real-time stock tracking. Optimistic locks to prevent overselling.
Payment service: Integrates with payment gateways. Idempotency, retry, reconciliation.
Recommendation service: "Customers who bought this also bought…" — pre-computed on clickstream data.
12. Taxi Booking (e.g., Uber, Lyft)
Requirements: Real-time driver location updates, rider requests nearby drivers, fare calculation, trip tracking, ETA prediction.
Challenges: Updating 10M driver locations every 3 seconds, finding nearest driver in <100ms, surge pricing.
Key Decisions:
Driver location: Store in Redis GEO data structure. Each city/region has a shard. Drivers publish location via WebSocket.
Rider request: Dispatch service queries Redis GEO for nearest drivers. Fan-out request to top 5 drivers via push notification.
Matching: First driver to accept gets the ride. Idempotency keys prevent double matching.
ETA: Pre-compute travel times from historical data + real-time traffic (Google Maps API).
Surge pricing: Algorithm runs every 5 minutes per region. High demand + low supply → multiplier applied.
13. Collaborative Editor (e.g., Google Docs, Notion)
Requirements: Multiple users editing the same document simultaneously, real-time cursor visibility, conflict resolution, version history.
Key Approaches:
OT (Operational Transformation): Each edit is an operation (insert "a" at position 5). Operations are transformed against concurrent operations to converge.
CRDT (Conflict-Free Replicated Data Types): Each character has a unique ID. Edits commute and converge without central coordination. Easier to implement at scale.
WebSocket: Persistent connection for broadcasting edits and cursors.
Version history: Store snapshots + operation log for undo/redo and history browsing.
# CRDT character example (simplified)
Char { id: "user1:42", value: "a", position: [3, "user1:40"] }
Insert operation: insert character with ID between two existing positions
Positions form a linked list; concurrent inserts converge naturally
Exercise: Pick two case studies from this chapter that interest you most. For each, write the complete 4-step design (Problem → Scale → HLD → Infra Decisions → Final Design). Include trade-off analysis. Aim for 2—3 handwritten pages per study.