The goal is to demonstrate a practical, modern approach to System Design. After introducing the questions we are going to be building and scaling a global video platform, suitable for system design interviews.

System Design interview questions

1. URL Shortening Service (e.g., bit.ly)

   • Goal: Generate short, unique aliases for long URLs and redirect with high availability.
   • Considerations: ID generation (base62, hash, collision handling), data model, read-heavy workload, caching, analytics, expiration, custom aliases, rate limiting, and analytics storage.

2. Web Cache Design / CDN

   • Goal: Cache static or semi-static content near users to reduce latency and origin load.
   • Considerations: Cache keys, TTLs, invalidation, cache coherency, origin failover, cache warming, CDN vs edge compute, cache hierarchy (L1-L4).

3. URL Autocomplete / Search Autocomplete

   • Goal: Provide fast prefix-based suggestions as users type.
   • Considerations: Data structures (tries, prefix trees), ranking (popularity, recency), sharding, caching, latency (<50–200ms), and online updates.

4. Translation Service (e.g., Google Translate)

   • Goal: Translate text between languages with low latency and high throughput.
   • Considerations: Model serving (batch vs online), caching common translations, model size and sharding, fallback/localization, quality metrics, and privacy for user text.

5. Parking Lot Design (physical sensors + app)

   • Goal: Track available spots, show real-time availability, and route users.
   • Considerations: Real-time telemetry ingestion, sensor reliability, geospatial indexing, aggregation, offline handling, and edge vs cloud processing.

6. Online Coding Judge (e.g., LeetCode)

   • Goal: Accept code submissions, run in isolated sandboxes, score and return results.
   • Considerations: Worker pool isolation (containers), sandboxing, queuing/backpressure, timeouts & resource limits, scaling runners, and plagiarism detection.

7. Distributed DB (Cassandra-like)

   • Goal: Provide a highly available, partition-tolerant key-value store at large scale.
   • Considerations: Partitioning strategy, replication factor, consistency levels (QUORUM/ONE), hinted handoff, anti-entropy repair, compaction, and monitoring.

8. Cloud Storage (Google Drive / Dropbox)

   • Goal: Store user files reliably with sync, sharing, and versioning.
   • Considerations: Object storage backend, metadata DB, deduplication, chunking & upload API, conflict resolution, sync clients, ACLs and encryption.

9. Social Network Feed (e.g., Facebook/Instagram)

   • Goal: Deliver personalized news-feed to users with low read latency.
   • Considerations: Fan-out vs fan-in, precompute vs on-the-fly aggregation, ranking signals, cache invalidation, storage for timelines, and anti-spam moderation.

10. Messaging System / Chat (e.g., WhatsApp)

    • Goal: Deliver messages (1:1 and group) reliably and quickly.
    • Considerations: Message ordering, delivery semantics (at-least-once, at-most-once), message queues, offline delivery, media handling, presence, and encryption.

11. Real-time Notifications / Push System

    • Goal: Push timely notifications to users across devices.
    • Considerations: Fan-out efficiency, TTL, device tokens, push providers (APNs/FCM), deduplication, user preferences, and rate limiting.

12. Matchmaking System (e.g., Tinder)

    • Goal: Match users based on preferences and signals.
    • Considerations: Geospatial queries, scoring/ranking, near-real-time matching, fairness, A/B experimentation, and scaling candidate generation.

13. Photo/Image Hosting & Thumbnailing

    • Goal: Store images and generate thumbnails/variants for different devices.
    • Considerations: On-upload processing pipeline, background jobs, content-addressable storage, CDN, responsive images, and cost for stored variants.

14. Video Streaming Service (HLS/DASH)

    • Goal: Deliver adaptive bitrate streaming to viewers worldwide.
    • Considerations: Chunking/segmenting, CDN integration, ABR algorithms, origin scaling, transcoding pipeline, and DRM for protected content.

15. Recommendation System (collaborative/filtering/ML)

    • Goal: Suggest relevant items (videos, products, friends) to users.
    • Considerations: Offline model training, online feature store, latency constraints, A/B testing, cold-start, and fairness/bias mitigation.

16. Search Engine (web or site search)

    • Goal: Index documents and serve ranked search results quickly.
    • Considerations: Crawling/indexing pipeline, inverted index, sharding, ranking signals, relevance tuning, caching, and near-real-time updates.

17. Ad Serving Platform

    • Goal: Serve targeted ads with real-time bidding and tracking.
    • Considerations: Low-latency auctions, targeting and segmentation, frequency capping, billing/measurement, fraud detection, and privacy controls.

18. Rate Limiter / Quota Service

    • Goal: Enforce request quotas or rate limits per user/API key.
    • Considerations: Token bucket vs leaky bucket, distributed counters, eventual consistency, client-side hints, and throttling strategies.

19. Event Streaming / Analytics Pipeline (e.g., Kafka + Flink)

    • Goal: Ingest and process high-volume event streams for metrics and analytics.
    • Considerations: Ordering, partitioning, backpressure, exactly-once vs at-least-once processing, storage retention, and windowing.

20. Metrics & Monitoring System

    • Goal: Collect, store, and alert on system metrics and logs.
    • Considerations: Cardinality control, retention, alerting thresholds, visualization, tracing correlations, and storage cost trade-offs.

21. Payment Processing System

    • Goal: Authorize and settle user payments securely.
    • Considerations: PCI compliance, idempotency, retries, fraud detection, reconciliation, multi-currency, and settlement delays.

22. Search Autocomplete / Query Suggestions (large scale)

    • Goal: Provide relevant suggestions with low latency at large QPS.
    • Considerations: Hot/cold data splits, precomputation, scoring, per-region personalization, and cache efficiency.

23. Feature Flagging Service

    • Goal: Toggle features for users safely and roll out gradually.
    • Considerations: SDKs and polling/streaming, targeting rules, rollout strategies (percentage, cohorts), auditing, and performance impact.

24. Map Tile Service / Geospatial Tiles

    • Goal: Serve map tiles and geospatial queries efficiently.
    • Considerations: Tile generation, caching/CDN, vector vs raster tiles, spatial indexing, and load hotspots.

25. Email Delivery Service (transactional)

    • Goal: Send reliable transactional emails with high deliverability.
    • Considerations: SMTP providers vs self-hosted, bounce handling, DKIM/SPF/DMARC, rate limits, templates, and analytics.

26. CI/CD System at Scale

    • Goal: Build and deploy software reliably across many services.
    • Considerations: Artifact storage, runner scalability, isolation, caching builds, dependency graph scheduling, and rollback strategies.

27. Distributed Lock Service (e.g., etcd/Consul/Redlock)

    • Goal: Provide coordination primitives across services.
    • Considerations: Failure modes, lease semantics, leader election, clock skew, and throughput limits.

28. Logging Pipeline / Centralized Logs

    • Goal: Collect and query application logs across the fleet.
    • Considerations: Ingestion throughput, indexing costs, retention, structured logging, and secure access.

29. File Sync & Offline-First Clients

    • Goal: Keep files in sync across devices with offline edits.
    • Considerations: Conflict resolution, operational transforms or CRDTs, efficient diffs, retry/backoff, and metadata store.

30. Throttling & Backpressure Patterns

    • Goal: Protect services from overload while providing graceful degradation.
    • Considerations: Circuit breakers, bulkheads, adaptive throttling, queue limits, shed load strategies, and graceful responses.

Notes and practice tips:

• For interviews, pick 4–6 components to deep-dive (API design, data model, scaling, and failure modes).
• Sketch the high-level architecture first, then discuss bottlenecks and optimizations.
• Quantify expected scale (QPS, storage, bandwidth) and justify choices.

Approaching System Design of Video Platform (e.g. Youtube)

Technical & Business Requirements

The platform must enable users to upload, manage and stream video content at scale, supporting a seamless experience across devices and geographies. Users should be able to create personal or branded channels, publish videos with metadata (title, description, tags) and interact with content through likes, comments and shares. The system must support user authentication, personalized recommendations and real-time notifications for subscriptions and interactions. Search functionality should allow users to discover content based on relevance, popularity and preferences.

From a business perspective, the system must ensure high availability, scalability and performance to support billions of daily interactions. It should enable content moderation workflows to maintain community standards and comply with legal regulations. Analytics capabilities must provide insights into user engagement, video performance and platform health. The architecture should support modular growth, allowing teams to independently develop and deploy features aligned with business capabilities such as video management, user engagement and content discovery.

Nouns and Verbs from Video Platform Requirements

Verbs

Key DDD Concepts Identified:

• Entities: Things with identity that change over time (Users, Videos, Channels, Comments)
• Value Objects: Immutable descriptors (Metadata, Tags, Preferences)
• Domain Events: Significant business occurrences (VideoUploaded, UserSubscribed)
• Domain Services: Business logic that doesn’t belong to entities (Search, Moderation)
• Aggregates: Consistency boundaries (Video + Metadata, User + Channels)

8 Bounded Contexts emerged naturally from the requirements:

• User Management
• Content Management
• Engagement
• Discovery
• Notification
• Analytics
• Moderation
• Content Delivery

Ubiquitous Language: Defined key terms that should be used consistently across the development team and business stakeholders. This DDD analysis provides a much stronger foundation for:

Microservices architecture design

• Team organization
• API boundaries
• Database design
• Business rule implementation

1. Requirements Gathering

Functional Requirements

• Video Upload: Users can upload videos (multiple formats, sizes up to 10GB)
• Video Streaming: Users can watch videos with adaptive bitrate streaming
• Video Search: Search videos by title, description, tags, channel
• User Management: Registration, authentication, profiles, subscriptions
• Social Features: Comments, likes/dislikes, sharing, playlists
• Channel Management: Create channels, manage content, analytics
• Content Moderation: Automated and manual content review
• Notifications: Subscription updates, comment replies, trending content

Non-Functional Requirements

User Scale

• Total registered users: 2+ billion
• Daily active users (DAU): 500+ million
• Monthly active users (MAU): 1.5+ billion
• Concurrent users (peak): 50+ million

System Throughput

• Video uploads: 500+ hours of content uploaded per minute
• Video consumption: 1+ billion hours watched daily
• Search queries: 1+ billion queries per day

Availability & Reliability

• Uptime SLA: 99.9% globally
• CAP Theorem priority:
  • Prioritize Availability and Partition Tolerance
  • Accept Eventual Consistency where applicable

Performance & Latency

• Video start time: < 2 seconds globally
• Search results latency: < 300 milliseconds
• Upload processing time: Variable (based on video size and format)
• Page load time (95th percentile): < 1 second

Consistency & Data Integrity

• User authentication & billing: Strong consistency
• Social features (likes, comments, views): Eventually consistent
• Content metadata updates: Eventually consistent

Storage & Data Management

• Video storage: Exabyte-scale, globally distributed
• Metadata storage: Highly available, low-latency key-value store
• Backup & disaster recovery: Geo-redundant with RPO < 1 hour

Bandwidth & Traffic

• Daily data transfer: Petabyte-scale
• Peak bandwidth usage: 100+ Tbps globally
• CDN usage: Aggressive caching and edge delivery for video content

Security & Compliance

• Data encryption: At rest and in transit
• Access control: Role-based and region-aware
• Compliance: GDPR, CCPA and other regional regulations

Scale Estimation

• Users: 2.7B monthly active users
• Videos: 720,000 hours uploaded daily
• Storage: 1PB+ new content daily
• Bandwidth: 30PB+ daily egress traffic
• QPS: 1M+ concurrent video streams

Introduction to Patterns to achieve NFR

1. Transactions & Consistency

• Two-Phase Commit (2PC) — classic distributed commit protocol for atomic commits across multiple resources (heavy, blocking).
• Three-Phase Commit (3PC) — non-blocking variant of 2PC with extra phase (rare in practice).
• XA / Distributed DB Transactions — vendor support for distributed transactions (JTA/XA); useful when available but reduces scalability.
• TCC (Try-Confirm/Cancel) — explicit Try / Confirm / Cancel steps for compensatable remote transactions.
• Saga (Choreography / Orchestration) — long-running transactions using local ACID steps + compensations.
• Compensating Transactions — undo actions when a multi-step workflow fails.
• Transactional Outbox — make DB write + outgoing message atomic by writing the message to an outbox table in the same transaction.
• Inbox / Idempotent Receiver — persist processed message IDs to avoid double processing.
• Quorum Reads/Writes — use majority quorums for consistency in distributed stores (Cassandra, Riak).
• Snapshot Isolation / MVCC — reduce read/write conflicts using multi-versioning.

2. Scaling & Capacity Patterns

• Horizontal Scaling — add more instances to increase capacity.
• Vertical Scaling — increase instance resources (CPU, RAM).
• Sharding / Partitioning — split data by key to distribute load.
• Read Replicas — scale reads by replicating primary DB.
• CQRS (Command Query Responsibility Segregation) — separate read/write models to scale each side independently.
• Event-Driven / Work Queues — decouple producers/consumers to absorb bursts.
• Autoscaling (HPA / Cluster autoscaler) — auto add/remove capacity based on metrics.
• Batching / Aggregation — reduce per-message overhead by batching.
• Fan-out / Fan-in Patterns — split work to many workers then aggregate results.
• Tiered Storage (Hot/Warm/Cold) — store frequently accessed vs archive data differently.

3. Data Management & Storage

• Event Sourcing — store state as a sequence of events; rebuild state by replay.
• Change Data Capture (CDC) — capture DB changes for replication or messaging.
• Append-Only Logs — simplify correctness and replication (Kafka style).
• Materialized Views — precompute query results for fast reads.
• Polyglot Persistence — choose the right DB type per use case.
• Snapshots & Checkpointing — speed up rebuilds of event-sourced state.
• TTL / Retention Policies — manage storage growth with time-based expiry.

4. Messaging & Integration Guarantees

• At-Least-Once Delivery — messages may be delivered multiple times; require idempotency.
• At-Most-Once Delivery — messages may be lost but never duplicated.
• Exactly-Once Semantics (EOS) — typically approximated by idempotency + dedup + transactional outbox/CPS.
• Message Deduplication / Idempotency Keys — detect and ignore duplicates.
• Message Ordering / Partitioning — preserve order per key where required.
• Dead-Letter Queue (DLQ) — isolate messages that repeatedly fail processing.
• Poison Message Handling — quarantine or transform problematic messages.
• Message Batching / Compression — improve throughput and reduce overhead.

5. Concurrency & Coordination

• Optimistic Concurrency Control (OCC) — detect conflicts on commit (version checks).
• Pessimistic Locking — acquire locks to prevent concurrent modifications.
• Distributed Locking (Redlock, ZK, etcd) — coordinate access to shared resources across nodes.
• Leader Election — elect a single coordinator for tasks (Raft/ZooKeeper).
• Consensus Algorithms (Raft, Paxos) — ensure replicated state agreement.
• Lease / Time-bounded Locks — avoid forever-held locks by using leases.

6. Availability & Resilience

• Retry with Backoff — handle transient failures without overloading services.
• Circuit Breaker — stop repeated calls to a failing service, fail fast.
• Bulkhead — isolate resource pools to prevent cascading failures.
• Fail-Fast — quickly reject requests when you know they’ll fail.
• Timeouts — avoid resource exhaustion from long waits.
• Fallback / Graceful Degradation — provide an alternative response when a dependency fails.
• Load Balancing — distribute load across healthy instances.
• Health Checks — detect and remove unhealthy instances from rotation.
• Service Mesh Resiliency — centralize retries, timeouts, circuit breaking at network layer.
• Multi-Region Deployment — survive entire region outages.
• Active-Active Deployment — all regions handle traffic simultaneously for HA.
• Quorum / Majority Replication — ensure availability while preserving consistency trade-offs.
• Active-Passive Failover — standby instance takes over on primary failure.
• Connection Draining / Graceful Shutdown — finish inflight requests before stopping an instance.
• Sticky Sessions vs Stateless Services — prefer stateless for scale; sticky only when required.
• Fallback Data Sources — degrade to cached or stale data on upstream failure.

7. Performance & Latency

• Edge Caching / CDN — serve static or near-static content from the edge.
• Cache-Aside / Write-Through / Write-Behind — cache strategies for read/write patterns.
• Prefetching / Read-Ahead — reduce perceived latency by loading likely data.
• Pipelining & Connection Reuse — reduce RTTs by reusing connections and pipelining requests.
• Compression / Encoding — reduce payload sizes.
• Locality of Reference — colocate compute and data to reduce latency.

8. Fault Tolerance & Disaster Recovery

• Backups & Point-in-Time Restore (PITR) — recover from data loss.
• Cross-Region Replication — replicate data to another region for DR.
• RPO / RTO Planning — define acceptable data loss and recovery time.
• Warm / Cold Standby — pre-provisioned or standby environments for failover.
• Chaos Engineering — proactively test failure modes and recovery.
• Automatic Failover Orchestration — scripted or automated failover to reduce MTTR.

9. Observability, Testing & SRE Practices

• SLO / SLI / SLA — define and measure service objectives and limits.
• Distributed Tracing (correlation IDs) — trace requests across services.
• Centralized Metrics & Logging — aggregate telemetry for alerting and forensics.
• Synthetic Monitoring / Health Probes — proactively detect regressions.
• Contract Testing (Consumer-Driven Contracts) — ensure API compatibility.
• Chaos / Failure Injection — validate resiliency in production-like environments.
• Runbooks & Playbooks — documented operational responses for incidents.

10. Security & Compliance

• mTLS & Mutual Authentication — secure service-to-service traffic.
• Secrets Management / Rotation — rotate keys/secrets (Vault, cloud KMS).
• Encryption (At-rest / In-transit) — protect data confidentiality.
• Audit Logging & Tamper-evidence — record actions for forensics & compliance.
• Data Masking / Tokenization / Anonymization — protect PII in non-prod or analytics.
• Least Privilege / RBAC / ABAC — minimize access surfaces.
• Rate Limiting & Throttling — prevent abuse and DoS attacks.

11. Deployability, Upgrade & Migration

• Schema Migration Strategies (expand-contract) — change DB schema safely without downtime.
• Backward/Forward Compatible APIs — design APIs to allow version-tolerant upgrades.
• Feature Flags / Toggling — control rollout and rollback of features safely.
• Blue-Green / Canary / Rolling Releases — reduce risk during deployment.
• Database Versioning & Migration Tools — track and apply DB changes reliably.
• Forklift / Strangler Fig Pattern — gradually replace legacy systems with new components.

12. Cost, Efficiency & Operational Economics

• Right-sizing — match instance types to workload.
• Spot / Preemptible Instances — cost savings for non-critical workloads.
• Serverless for Spiky Loads — pay-per-use for unpredictable bursts.
• Capacity Reservation / Savings Plans — lower cost for steady workloads.
• Tiered Storage & Archival — move cold data to cheaper storage tiers.
• Chargeback / Cost Allocation — attribute costs to teams or services.

13. Developer Productivity & Maintainability

• API First / Spec-Driven Development — generate SDKs and tests from a spec (OpenAPI).
• Semantic Versioning & Deprecation Policy — manage breaking changes predictably.
• Shared Libraries & Platform Services — reduce duplication and improve consistency.
• Automated CI/CD Pipelines — test and ship changes quickly and safely.
• Documentation as Code / Living Docs — keep docs versioned and near code.

14. Governance & Policy

• Policy-as-Code / RBAC Automation — enforce org policies automatically.
• Schema Registry / Compatibility Rules — control event/contract evolution.
• SLO Governance & Error Budgets — tie releases and risk to objective metrics.
• Service Catalog / Ownership Records — know who owns what and how to contact them.

2. High-Level Architecture

[CDN Layer] → [Load Balancers] → [API Gateway] → [Microservices]
                                                      ↓
[Message Queue] ← [Video Processing Pipeline] ← [Object Storage]
                                                      ↓
[Search Engine] ← [Metadata Services] → [Analytics Pipeline]

Core Components

1. API Gateway - Request routing, authentication, rate limiting
2. Video Upload Service - Handle video ingestion and initial processing
3. Video Processing Pipeline - Transcoding, thumbnail generation, ML analysis
4. Video Streaming Service - Adaptive bitrate delivery
5. Metadata Service - Video information, user data, social interactions
6. Search Service - Video discovery and recommendation
7. User Service - Authentication, profiles, subscriptions
8. Analytics Service - View tracking, performance metrics
9. Notification Service - Real-time updates and alerts

2a. Microservice Decomposition & Hexagonal Architecture (Chris Richardson)

Decomposition Strategies (from “Microservices Patterns”)

• By Business Capability: Decompose services around business domains (e.g., Video Management, User Management, Social Interactions, Analytics).
• By Subdomain (DDD): Identify core, supporting and generic subdomains (e.g., Video Processing as core, Notification as supporting).
• By Transaction Boundary: Services should own their data and transactional boundaries (e.g., Video Upload and Processing as separate services).
• By Team Ownership: Align services with team boundaries for independent delivery.

Hexagonal Architecture (Ports & Adapters)

• Service Core: Business logic is isolated from external systems.
• Ports: Define interfaces for driving (API, UI) and driven (DB, messaging, external APIs) adapters.
• Adapters: Implement ports for REST, gRPC, Kafka, databases, etc.
• Benefits: Improves testability, flexibility and separation of concerns.

Example: Video Upload Service (Hexagonal)

• Core: Handles upload validation, metadata extraction and orchestration.
• Inbound Adapter: REST API for receiving uploads.
• Outbound Adapters: Kafka producer for events, S3 adapter for storage, DB adapter for metadata.

Additional Patterns from the Book

• API Composition: Aggregate data from multiple services for UI.
• Database per Service: Each service owns its schema.
• Saga Pattern: Manage distributed transactions (e.g., video upload workflow).
• CQRS: Separate read/write models for scalability.
• Event Sourcing: Persist state changes as events for auditability.
• Service Mesh: Use a service mesh (e.g., Istio, Linkerd) for managing service-to-service communication, observability and security.
• Externalized Configuration: Store configuration outside the service for flexibility and easier deployments.
• Centralized Log Management: Aggregate logs for all services to enable monitoring and troubleshooting.
• Health Check API: Each service exposes a health check endpoint for orchestration and monitoring.
• Consumer-Driven Contracts: Ensure service integrations are reliable and changes do not break consumers.
• Testing Strategies: Include contract testing, component testing and end-to-end testing for microservices.
• Distributed Tracing: Implement tracing to follow requests across service boundaries for observability.
• Service Template/Boilerplate: Use standardized templates to accelerate new service development and enforce best practices.

3. Scale Cube Application for 10x Growth

X-Axis Scaling (Horizontal Duplication)

• Load Balancers: Deploy multiple tiers (L4/L7) with auto-scaling
• API Gateway Clusters: Regional deployment with intelligent routing
• Microservice Replicas: Auto-scaling based on CPU, memory and queue depth
• Database Read Replicas: Multiple read-only instances per region

Y-Axis Scaling (Functional Decomposition)

• Service Decomposition:
  • Upload Service → Video Ingestion + Metadata Extraction + Storage
  • User Service → Auth + Profile + Subscription + Preferences
  • Social Service → Comments + Likes + Sharing + Community
• Database Decomposition: Separate DBs for videos, users, analytics, social
• Event-Driven Architecture: Loose coupling via message queues

Z-Axis Scaling (Data Partitioning)

• Video Sharding: By video ID hash, geographic region, or creator
• User Sharding: By user ID hash or geographic region
• Temporal Sharding: Hot data (recent) vs cold data (archived)
• Content-Based Sharding: By video category, language, or popularity

4. Microservices Design Patterns

Service Patterns

• API Gateway Pattern: Single entry point with cross-cutting concerns
• Service Registry & Discovery: Consul/Eureka for service location
• Circuit Breaker: Hystrix for fault tolerance and cascading failure prevention
• Bulkhead: Resource isolation between services
• Retry with Exponential Backoff: Resilient inter-service communication

Data Patterns

• Database per Service: Each microservice owns its data
• Saga Pattern: Distributed transactions for video upload workflow
• CQRS: Separate read/write models for video metadata and analytics
• Event Sourcing: Audit trail for user actions and video lifecycle

Communication Patterns

• Asynchronous Messaging: Kafka for video processing pipeline

• Request-Response: HTTP/gRPC for real-time user interactions

• Publish-Subscribe: Event notifications for subscriptions

• Message Routing: Content-based routing for different video types

• Hexagonal Architecture: Each service is designed using ports and adapters, isolating business logic from infrastructure.

• Decomposition by Business Capability: Services are split by domain, following DDD and team boundaries.

• Saga Pattern: Used for workflows like video upload and processing.

• CQRS & Event Sourcing: Applied for scalability and auditability.

5. Event-Driven Architecture (EDA)

Event Streaming Platform

Video Upload → [Event Producer] → [Kafka Topics] → [Event Consumers] → Processing Services

Core Events

• VideoUploadedEvent: Triggers transcoding pipeline
• VideoProcessedEvent: Updates metadata and makes video available
• UserActionEvent: Likes, comments, views for recommendation engine
• SubscriptionEvent: Channel subscription/unsubscription
• ModerationEvent: Content review results

Event Patterns

• Event Sourcing: Store all state changes as events
• CQRS: Separate command and query responsibility
• Event Choreography: Services react to events autonomously
• Event Orchestration: Central coordinator for complex workflows

6. CAP Theorem Considerations

Design Decisions

• Partition Tolerance: Always required in distributed system
• Availability vs Consistency Trade-offs:
  • AP Systems: Video streaming, comments, likes (eventual consistency)
  • CP Systems: User authentication, payment processing
  • CA Systems: Single-region components with strong consistency

Implementation Strategy

• Multi-Region Deployment: Handle network partitions
• Eventual Consistency: Social features can tolerate temporary inconsistency
• Strong Consistency: Critical operations like user authentication
• Conflict Resolution: Last-writer-wins, vector clocks for concurrent updates

7. Storage Architecture

Video Storage

• Object Storage: S3/GCS for raw and processed video files
• CDN: CloudFront/CloudFlare for global content delivery
• Storage Tiers: Hot (recent), warm (popular), cold (archived)
• Compression: AV1 codec for 30% bandwidth savings

Metadata Storage

• Relational Database: PostgreSQL for structured data (users, videos)
• Document Database: MongoDB for flexible schemas (comments, analytics)
• Graph Database: Neo4j for social relationships and recommendations
• Cache Layer: Redis for frequently accessed data

Search Index

• Elasticsearch: Full-text search for videos, channels, playlists
• Vector Database: Pinecone for ML-based video recommendations
• Real-time Indexing: Stream processing for immediate search availability

8. Video Processing Pipeline

Processing Stages

1. Ingestion: Upload validation, virus scanning, metadata extraction
2. Transcoding: Multiple resolutions, formats and bitrates
3. AI Processing: Content analysis, thumbnail generation, closed captions
4. Quality Check: Automated quality assessment and optimization
5. Distribution: CDN upload and cache warming

Technologies

• Message Queue: Apache Kafka for pipeline orchestration
• Container Orchestration: Kubernetes for scalable processing
• Workflow Engine: Apache Airflow for complex processing workflows
• ML Platform: TensorFlow Serving for content analysis

9. Scaling Strategies for 10x Growth

Infrastructure Scaling

• Multi-Cloud: AWS, GCP, Azure for redundancy and cost optimization
• Edge Computing: Process videos closer to users
• Serverless: Lambda/Cloud Functions for variable workloads
• Auto-scaling: Predictive scaling based on usage patterns

Performance Optimization

• Caching Strategy:
  • L1: Browser cache (static content)
  • L2: CDN cache (popular videos)
  • L3: Application cache (metadata)
  • L4: Database cache (query results)

Data Management

• Data Archiving: Move old content to cheaper storage tiers
• Data Compression: Advanced codecs and compression algorithms
• Smart Prefetching: ML-based content prediction and caching
• Geographic Optimization: Content placement based on user location

10. Monitoring and Observability

Metrics

• Golden Signals: Latency, traffic, errors, saturation
• Business Metrics: Video start failures, buffering ratio, user engagement
• Infrastructure Metrics: CPU, memory, network, storage utilization

Tools

• Monitoring: Prometheus, Grafana, DataDog
• Logging: ELK Stack (Elasticsearch, Logstash, Kibana)
• Tracing: Jaeger, Zipkin for distributed tracing
• Alerting: PagerDuty for incident management

11. Security Considerations

Content Security

• DRM: Widevine, FairPlay for premium content protection
• Content Filtering: ML-based inappropriate content detection
• Access Control: JWT tokens, OAuth 2.0, rate limiting

Infrastructure Security

• Network Security: VPC, security groups, WAF
• Encryption: TLS in transit, AES-256 at rest
• Secrets Management: HashiCorp Vault, AWS Secrets Manager
• Compliance: GDPR, COPPA, regional data protection laws

12. Cost Optimization

Storage Optimization

• Intelligent Tiering: Automatic movement between storage classes
• Deduplication: Remove duplicate video segments
• Compression: Advanced codecs (AV1, H.265) for bandwidth savings
• Regional Optimization: Store content closer to primary audience

Compute Optimization

• Spot Instances: Use for batch processing jobs
• Right-sizing: ML-based instance size recommendations
• Reserved Capacity: Long-term commitments for predictable workloads
• Serverless: Pay-per-use for variable workloads

13. Disaster Recovery and Business Continuity

Backup Strategy

• Multi-Region Replication: Critical data replicated across regions
• Point-in-Time Recovery: Database snapshots and transaction logs
• Content Backup: Multiple copies of popular content

Recovery Procedures

• RTO (Recovery Time Objective): 15 minutes for critical services
• RPO (Recovery Point Objective): 5 minutes for user data
• Failover Automation: Automated traffic rerouting during outages
• Chaos Engineering: Regular disaster simulations

14. Key Principles and Laws Applied

Performance Laws

• Little’s Law: Average number of items in a queuing system equals the average arrival rate multiplied by the average time an item spends in the system.
• Amdahl’s Law: The speedup of a program from parallelization is limited by the sequential portion.
• Universal Scalability Law: Models the impact of contention and coherency delays in distributed systems.

Design Principles

• Single Responsibility Principle: Each service has one clear purpose.
• Open/Closed Principle: Services should be open for extension, closed for modification.
• Dependency Inversion Principle: Depend on abstractions, not concretions.
• Fail Fast: Detect and report errors immediately.

Reliability Patterns

• Bulkhead: Isolate resources to prevent cascading failures.
• Circuit Breaker: Prevent calls to failing services.
• Timeout: Set maximum wait times for all operations.
• Idempotency: Safe to retry operations multiple times.

Additional Laws and Principles

• Murphy’s Law: “Anything that can go wrong will go wrong.” Design for failure and recovery.
• Conway’s Law: System design mirrors the communication structure of the organization.
• Occam’s Razor: Prefer the simplest solution that works.
• Robustness Principle (Postel’s Law): “Be conservative in what you send, be liberal in what you accept.”
• Law of Demeter: Minimize coupling by only interacting with immediate collaborators.
• Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
• Pareto Principle (80/20 Rule): 80% of effects come from 20% of causes; optimize for the critical path.
• Peter Principle: In hierarchical organizations, people tend to be promoted to their level of incompetence (impacts team/org design).
• Gall’s Law: A complex system that works is invariably found to have evolved from a simple system that worked.

15. Database Design

User Service Database

-- Users table
CREATE TABLE users (
    user_id BIGINT PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW(),
    last_login TIMESTAMP
);

-- Channels table
CREATE TABLE channels (
    channel_id BIGINT PRIMARY KEY,
    user_id BIGINT REFERENCES users(user_id),
    channel_name VARCHAR(100) NOT NULL,
    description TEXT,
    subscriber_count BIGINT DEFAULT 0,
    created_at TIMESTAMP DEFAULT NOW()
);

-- Subscriptions table (sharded by user_id)
CREATE TABLE subscriptions (
    subscription_id BIGINT PRIMARY KEY,
    subscriber_id BIGINT REFERENCES users(user_id),
    channel_id BIGINT REFERENCES channels(channel_id),
    subscribed_at TIMESTAMP DEFAULT NOW(),
    UNIQUE(subscriber_id, channel_id)
);

Video Service Database

-- Videos table (sharded by video_id hash)
CREATE TABLE videos (
    video_id BIGINT PRIMARY KEY,
    channel_id BIGINT NOT NULL,
    title VARCHAR(255) NOT NULL,
    description TEXT,
    duration INTEGER, -- in seconds
    view_count BIGINT DEFAULT 0,
    like_count BIGINT DEFAULT 0,
    dislike_count BIGINT DEFAULT 0,
    upload_time TIMESTAMP DEFAULT NOW(),
    processing_status ENUM('uploading', 'processing', 'ready', 'failed'),
    visibility ENUM('public', 'private', 'unlisted')
);

-- Video metadata table
CREATE TABLE video_metadata (
    video_id BIGINT PRIMARY KEY REFERENCES videos(video_id),
    file_size BIGINT,
    codec VARCHAR(50),
    resolution VARCHAR(20),
    bitrate INTEGER,
    thumbnail_url VARCHAR(500),
    tags TEXT[] -- PostgreSQL array for tags
);

-- Comments table (sharded by video_id)
CREATE TABLE comments (
    comment_id BIGINT PRIMARY KEY,
    video_id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    parent_comment_id BIGINT, -- for replies
    content TEXT NOT NULL,
    like_count INTEGER DEFAULT 0,
    created_at TIMESTAMP DEFAULT NOW()
);

16. API Design

REST API Endpoints

Video Operations

# Upload video
POST /api/v1/videos
Content-Type: multipart/form-data

# Get video details
GET /api/v1/videos/{videoId}

# Update video metadata
PUT /api/v1/videos/{videoId}

# Delete video
DELETE /api/v1/videos/{videoId}

# Search videos
GET /api/v1/videos/search?q={query}&limit={limit}&offset={offset}

# Get trending videos
GET /api/v1/videos/trending?category={category}&region={region}

User Operations

# User registration
POST /api/v1/users/register

# User login
POST /api/v1/users/login

# Get user profile
GET /api/v1/users/{userId}

# Subscribe to channel
POST /api/v1/users/{userId}/subscriptions/{channelId}

# Get user subscriptions
GET /api/v1/users/{userId}/subscriptions

Social Operations

# Like/Unlike video
POST /api/v1/videos/{videoId}/like
DELETE /api/v1/videos/{videoId}/like

# Add comment
POST /api/v1/videos/{videoId}/comments

# Get comments
GET /api/v1/videos/{videoId}/comments?limit={limit}&offset={offset}

# Reply to comment
POST /api/v1/comments/{commentId}/replies

GraphQL Schema (Alternative)

type Video {
  id: ID!
  title: String!
  description: String
  duration: Int!
  viewCount: Int!
  likeCount: Int!
  uploadTime: String!
  channel: Channel!
  comments(first: Int, after: String): CommentConnection
}

type Channel {
  id: ID!
  name: String!
  subscriberCount: Int!
  videos(first: Int, after: String): VideoConnection
}

type Query {
  video(id: ID!): Video
  searchVideos(query: String!, first: Int, after: String): VideoConnection
  trendingVideos(category: String, region: String): [Video!]!
}

type Mutation {
  uploadVideo(input: VideoInput!): Video
  likeVideo(videoId: ID!): Video
  addComment(videoId: ID!, content: String!): Comment
}

17. Caching Strategy

Multi-Level Caching

# Level 1: Browser Cache
- Static assets: 1 year
- Video thumbnails: 1 week
- API responses: 5 minutes

# Level 2: CDN Cache (CloudFlare/CloudFront)
- Video segments: 1 day
- Thumbnails: 1 week
- API responses: 1 minute

# Level 3: Application Cache (Redis)
- Popular video metadata: 1 hour
- User sessions: 24 hours
- Search results: 15 minutes
- Trending videos: 30 minutes

# Level 4: Database Query Cache
- Complex analytics queries: 5 minutes
- User profile data: 30 minutes
- Channel information: 1 hour

Cache Invalidation Strategy

• Time-based: TTL for most cached data
• Event-based: Invalidate on video updates, user actions
• Version-based: Cache keys include version numbers
• Write-through: Update cache and database simultaneously
• Write-behind: Async cache updates for non-critical data

18. Message Queue Architecture

Kafka Topic Design

# Video Processing Topics
video-upload-events:
  partitions: 100
  replication-factor: 3
  retention: 7 days

video-transcoding-jobs:
  partitions: 50
  replication-factor: 3
  retention: 3 days

video-ready-events:
  partitions: 100
  replication-factor: 3
  retention: 30 days

# User Activity Topics
user-view-events:
  partitions: 200
  replication-factor: 3
  retention: 90 days

user-interaction-events:
  partitions: 100
  replication-factor: 3
  retention: 30 days

# Notification Topics
subscription-notifications:
  partitions: 50
  replication-factor: 3
  retention: 7 days

Event Schema (Avro)

{
  "type": "record",
  "name": "VideoUploadEvent",
  "fields": [
    { "name": "videoId", "type": "string" },
    { "name": "userId", "type": "string" },
    { "name": "channelId", "type": "string" },
    { "name": "filename", "type": "string" },
    { "name": "fileSize", "type": "long" },
    { "name": "contentType", "type": "string" },
    { "name": "uploadTimestamp", "type": "long" },
    { "name": "metadata", "type": { "type": "map", "values": "string" } }
  ]
}

19. Load Balancing Strategy

Geographic Load Balancing

# DNS-based routing
Global Load Balancer:
  - US-East: 40% traffic
  - US-West: 20% traffic
  - Europe: 25% traffic
  - Asia-Pacific: 15% traffic

# Regional Load Balancers
Regional LB (L7):
  - Path-based routing: /api/upload → Upload Service
  - Header-based routing: User-Agent → Mobile/Web Service
  - Weighted routing: Canary deployments

# Service Load Balancers (L4)
Service Discovery:
  - Health checks every 30 seconds
  - Circuit breaker: 5 failures in 60 seconds
  - Load balancing algorithms: Weighted round-robin

Auto-scaling Configuration

# Horizontal Pod Autoscaler (Kubernetes)
Video Upload Service:
  minReplicas: 10
  maxReplicas: 100
  targetCPUUtilization: 70%
  targetMemoryUtilization: 80%
  scaleUpStabilization: 60s
  scaleDownStabilization: 300s

Video Streaming Service:
  minReplicas: 50
  maxReplicas: 500
  targetCPUUtilization: 60%
  customMetrics:
    - concurrent_streams_per_pod: 1000

20. Monitoring and Alerting

Key Metrics Dashboard

# Golden Signals
Latency:
  - Video start time: P50, P95, P99
  - API response time: P50, P95, P99
  - Upload processing time: P50, P95, P99

Traffic:
  - Requests per second by endpoint
  - Concurrent video streams
  - Upload requests per minute

Errors:
  - HTTP error rates (4xx, 5xx)
  - Video processing failures
  - Database connection errors

Saturation:
  - CPU utilization across services
  - Memory usage patterns
  - Queue depth in Kafka topics
  - Storage utilization

Alert Rules

# Critical Alerts (PagerDuty)
Video Start Failure Rate > 1%:
  severity: critical
  notification: immediate

API Error Rate > 5%:
  severity: critical
  notification: immediate

Database Connection Pool > 90%:
  severity: critical
  notification: immediate

# Warning Alerts (Slack)
Upload Processing Time > P95:
  severity: warning
  notification: 5-minute delay

CDN Cache Hit Rate < 85%:
  severity: warning
  notification: 10-minute delay

21. Additional Considerations and Patterns

Service Governance & Platform Engineering

• API Gateway Governance: Centralized API management, versioning and security policies.
• Service Catalog: Maintain a registry of all services, their owners and documentation.
• Platform as a Service (PaaS): Internal developer platforms for rapid service deployment and consistency.
• Service Lifecycle Management: Automated onboarding, deprecation and retirement of services.

Observability & Operations

• Distributed Tracing: End-to-end request tracing across all services.
• Log Correlation: Correlate logs, traces and metrics for faster root cause analysis.
• Proactive Anomaly Detection: ML-based monitoring for early detection of issues.
• Feature Flags: Gradual rollout and rollback of features without redeployments.

Security Enhancements

• Zero Trust Security Model: Authenticate and authorize every request, even within the internal network.
• API Rate Limiting & Throttling: Prevent abuse and ensure fair usage.
• Audit Logging: Immutable logs for all sensitive operations and access.

Compliance & Data Privacy

• Data Residency Controls: Ensure data is stored and processed in compliance with regional laws.
• User Data Portability & Deletion: GDPR-compliant APIs for user data export and erasure.
• PII Masking: Mask personally identifiable information in logs and analytics.

Advanced Data & ML

• Real-Time Analytics: Stream processing for instant insights (e.g., Apache Flink).
• A/B Testing Platform: Experiment with new features and recommendation algorithms.
• Personalization Engine: ML-driven recommendations, thumbnails and notifications.
• Content Fingerprinting: Detect duplicate or copyrighted content at scale.

Reliability Engineering

• Self-Healing Infrastructure: Automated detection and remediation of failed components.
• Chaos Engineering: Regularly inject failures to test system resilience.
• Disaster Recovery Drills: Scheduled simulations to validate recovery procedures.

Developer Experience

• Local Development Environments: Simulate production-like environments for testing.
• Automated Code Quality Checks: Linting, static analysis and security scanning in CI/CD.
• Comprehensive Documentation: Up-to-date API, architecture and operational docs.

Sustainability & Cost Controls

• Green Computing Initiatives: Optimize for energy efficiency and carbon footprint.
• Cost Visibility Dashboards: Real-time cost tracking per service and feature.
• Resource Quotas: Prevent runaway costs by enforcing limits.

Community & Ecosystem

• Open API Standards: Support for OpenAPI/GraphQL for third-party integrations.
• Plugin/Extension Framework: Allow external developers to extend platform capabilities.
• Community Moderation Tools: Empower users to help maintain content quality.

Conclusion

This comprehensive YouTube system design demonstrates how to architect a massive-scale video platform that can handle billions of users and petabytes of content. The design incorporates modern distributed systems principles, microservices architecture, event-driven patterns and advanced scaling techniques.

The 10x scaling strategy leverages the Scale Cube dimensions, applies CAP theorem principles strategically and utilizes cutting-edge technologies to ensure the platform remains performant, reliable and cost-effective as it grows. The architecture is designed to be resilient, observable and maintainable while providing an excellent user experience globally.