System Components: 1. Map Tile Service: World map pre-rendered into tiles at 21 zoom levels Tile naming: zoom/x/y.png (quadtree coordinates) Stored on Object Storage (GCS) served via CDN globally Vector tiles (modern): send vector data, render client-side (better scaling, dark mode) Tile generation pipeline: OSM data + satellite imagery Mapnik/custom renderer → tiles 2. Routing Engine: Road network = weighted directed graph Nodes: intersections Edges: road segments with weights (distance, speed_limit, traffic) Algorithm: Bidirectional Dijkstra (15x faster than one-directional) For Google-scale: Contraction Hierarchies (CH) precompute shortcuts Preprocess offline: add shortcut edges bypassing less important nodes Query: expand upward from src AND downward from dst meeting in middle Result: routes in <1ms even for continent-scale 3. Real-time Traffic: Driver location probes → Kafka (every 3s while driving, anonymized) Traffic aggregation service: compute avg speed per road segment (15s windows) Traffic overlay: Flink stream processor updates segment weights in Redis Routing engine reads current edge weights from Redis for ETA 4. ETA Prediction: Historical + real-time traffic + ML model (time of day, day of week, weather) Continually recalculate during navigation if user deviates or traffic changes 5. Search (POI): "Coffee near me" → Elasticsearch geo_distance query + ranking by ratings/distance Named search "Eiffel Tower" → Knowledge Graph (entity resolution) → coordinates Geocoding (address → lat/lng): Nominatim / in-house model Reverse geocoding (lat/lng → address): R-tree spatial index

Upload Flow: 1. Client chunks file into 4MB blocks (content-addressed: SHA256 of block) 2. Client checks: which blocks already exist? POST /api/check_blocks [sha256_list] 3. Server: SELECT sha256 FROM blocks WHERE sha256 IN (...) return existing 4. Client uploads ONLY missing blocks (delta sync — huge bandwidth savings) PUT /upload/block/{sha256} direct to S3 via pre-signed URL (bypass app servers) 5. Client: POST /api/commit_file {filename, block_list: [sha256s], parent_version} 6. Server: INSERT file record + version in MySQL, notify other devices via SSE/WebSocket Block Storage (Deduplication): blocks table: {sha256 (PK), s3_path, size, ref_count} files table: {file_id, user_id, version_id, block_list (JSON array of sha256s)} Two users upload same file? Both reference same blocks (storage saved!) Garbage collection: decrement ref_count on delete; S3 deletion when ref_count=0 File Metadata: MySQL: file hierarchy (parent_folder_id, name, user_id, permissions) Redis: active user sessions, recently accessed file metadata (hot cache) Elasticsearch: full-text filename search across all files Sync Protocol: Client maintains local delta log (what changed since last sync) Server sends: GET /changes?since=cursor (long-poll or WebSocket) Cursor: opaque token representing sync state (like Dropbox's /list_folder/continue) On change: server publishes event Kafka notifications-{userId} SSE/WebSocket push Conflict Resolution: Two devices edit file while offline, reconnect with divergent versions Strategy: keep BOTH files: "report.docx" + "report.docx (conflict copy, Device A, 2024-01-15)" User resolves manually (same as Dropbox behavior — don't attempt auto-merge for binary files)

Content Upload Pipeline (Studio → Users): Studio uploads raw 4K master → S3 (raw-content bucket) S3 event → Kafka "content-uploaded" topic Transcoding Fleet (GPU instances — EC2 P4d): Input: raw.mp4 FFmpeg transcodes to: 240p/360p/480p/720p/1080p/4K Codec: H.264 (compatibility) + HEVC/H.265 (60% smaller, for 4K) Output: HLS/DASH segments (.ts files, ~6s each) + .m3u8 manifests Upload segments → CDN Origin (S3 bucket closest to edge) Metadata: MySQL (title, cast, genre, synopsis, age_rating) Elasticsearch: title + genre + cast search Playback (Client → CDN): Client: GET /api/manifest/{contentId} → returns .m3u8 with CDN URLs Client requests segments: https://cdn-edge.netflix.com/show123/1080p/seg001.ts CDN edge (Open Connect Appliance — Netflix's own CDN hardware in ISP PoPs) Edge cache: 99%+ of popular content served directly from ISP network! Adaptive Bitrate (ABR): client monitors download speed If bandwidth drops: switch from 1080p manifest to 720p, seamless mid-stream Recommendation Engine: Offline: Spark batch jobs on viewing history → collaborative filtering (ALS matrix factorization) Near-real-time: Kafka stream → Flink updates user affinity scores Serving: pre-computed top-N recommendations per user stored in Cassandra Personalized thumbnails: A/B test different thumbnail images per user profile Resilience (Netflix Chaos Engineering): Circuit breakers between all microservices (Hystrix/Resilience4j) Chaos Monkey: randomly kills production instances (tests resilience) Multi-region active-active: US-East, US-West, EU, Asia Fallback: if recommendations unavailable → return editorial "top picks"

Architecture: URL Frontier (Priority Queue): Stores URLs to crawl, prioritized by: - PageRank estimate (important pages crawled more often) - Freshness score (last modified headers, update frequency) - Domain politeness (max 1 req/sec per domain) Implementation: Kafka topics per domain + Redis sorted set for priority Crawl Workers (stateless, horizontally scalable): Dequeue URL from Frontier DNS resolve (local cache + upstream) Fetch page (HTTP GET with User-Agent: Googlebot, respect robots.txt) Dynamic pages: headless Chrome (Puppeteer) for JS rendering Extract: all href links + raw HTML content Publish to Kafka: "pages-crawled" topic: {url, html, timestamp, status_code} "links-found" topic: {source_url, [discovered_urls]} Content Processing Pipeline: HTML Parser → extract text, metadata, canonical URL Dedup Service: SHA256(normalized_content) → Bloom Filter → URL Set check Duplicate? Skip. New? Store in object storage (S3), index in Elasticsearch URL Deduplication: Bloom filter (1B URLs, 1% FP rate, ~1.2GB RAM) — fast pre-check URL Set (Redis / DynamoDB) — authoritative dedup store URL normalization: lowercase, remove fragment, canonical redirect resolution robots.txt Compliance: Fetch and cache robots.txt per domain (TTL 24h) Before crawling any URL: check allow/disallow rules Crawl-delay directive respected Refresh Strategy: High-priority (news, social): re-crawl every 1h via separate high-frequency queue Normal pages: adaptive based on historical change rate (3 days if rarely changes) 404 pages: exponential backoff (1d, 4d, 16d), eventually discard URL

Payment Flow (Critical Path): 1. Client: POST /payments {amount, currency, payment_method_token, idempotency_key} 2. Payment Service: Check idempotency key (Redis NX) — if exists, return cached result 3. Fraud Detection Service (async check within 200ms): ML model: card velocity, geo anomaly, device fingerprint → risk score >0.8 risk: decline. 0.5-0.8: 3DS challenge. <0.5: proceed 4. PSP (Payment Service Provider) call: POST to Stripe/Adyen API — Tokenized card (PAN never stored on our servers — PCI-DSS scope reduction) — PSP charges card issuer via card network (Visa/MC rails) 5. On PSP response: SUCCESS: INSERT INTO ledger (txn_id, amount, status='completed') — ACID FAILURE: INSERT INTO ledger (txn_id, amount, status='failed') TIMEOUT: async reconciliation job checks PSP status endpoint 6. Return payment result to client 7. Async: emit PaymentCompleted event → Kafka → Order Service, Email, Analytics Double-Charge Prevention: Idempotency key (client-generated UUID) stored in Redis with TTL 24h PSP-level idempotency: pass our idempotency key in PSP request header DB: UNIQUE constraint on (idempotency_key) Ledger (Double-Entry Bookkeeping): Every financial event creates TWO entries (debit + credit): DEBIT: customer wallet $-50 CREDIT: merchant wallet $+50 (or escrow pending settlement) Sum of all ledger entries must always = 0 (invariant checked hourly) Append-only: never UPDATE ledger rows — only INSERT corrections Reconciliation: Nightly job: compare our ledger against PSP settlement report Mismatches (our-success + PSP-fail): auto-refund and alert Mismatches (our-fail + PSP-success): charge PSP for reverse or log for manual review

Photo Upload: Client → Upload Service (pre-signed S3 URL) → S3 (original) S3 event → Image Processing Worker (Kafka): Resize to: thumbnail (150px), feed (640px), HD (1080px), original Convert to WebP (30% smaller than JPEG) Generate perceptual hash (dHash) for duplicate detection Store all variants in S3, URLs in MySQL Feed Architecture (Hybrid Fan-out like Twitter): Follower count < 10K (regular users): Fan-out on write Post created → FanoutWorker → ZADD feed:{followerId} timestamp postId Feed stored in Redis Sorted Set per user Celebrity (>10K followers): Fan-out on read At read time: fetch latest N posts from celebrity's timeline directly Merge with user's pre-built feed (client or feed service merges) Feed Read: Redis ZRANGE feed:{userId} 0 50 → postIds Batch fetch post metadata from MySQL/Redis Batch fetch user metadata (avatar, username) from User Service cache Return assembled feed Stories: Upload same as photos, but metadata: TTL = created_at + 86400s Redis Sorted Set: stories:{userId} (score = expiry_time) Background job: ZREMRANGEBYSCORE remove expired stories Viewer set stored in Redis Set (story:{storyId}:viewers) with same TTL Explore Feed: Content-based: user's interest graph → candidate posts → ML ranking Collaborative filtering: users similar to you liked → show their liked posts Trending hashtags: sliding window count in Redis Likes Counter: Redis INCR likes:{postId} (in-memory, fast) Async flush to PostgreSQL every 60s (batch update) On read: check Redis first, fallback to DB

Architecture: Scheduler (Leader-elected via Zookeeper/etcd): Cron expressions → parse next N execution times (pre-compute 5min ahead) INSERT INTO task_queue (task_id, run_at, status='pending', priority) Leader heartbeat: if leader dies, Raft election for new scheduler leader Task Queue: Tier 1: Redis Sorted Set (score = run_at timestamp) High-frequency polling by dispatcher (every 100ms) ZRANGEBYSCORE task_queue -inf NOW LIMIT 0 100 → due tasks ZREM + atomically claim via Lua script (prevent double-dispatch) Tier 2: MySQL (durable, for recovery after Redis flush) Redis populated from MySQL on startup; MySQL is source of truth Dispatcher: Polls Redis every 100ms for due tasks Assigns to available worker via consistent hashing (task_type → worker pool) Worker heartbeats via Redis key (worker:{id} EX 30s) On heartbeat miss: task reassigned (at-least-once delivery) Workers (stateless pool): Long-poll dispatcher queue or subscribe to Kafka topic per task_type Execute task logic (idempotent!) On completion: UPDATE task_executions SET status='done', result=... WHERE id=... On failure: retry with exponential backoff (max_retries configurable) Poison pills (always-failing): move to DLQ after max_retries DAG Dependencies: task_dependencies table: {task_id, depends_on_task_id} After task completes: check if any downstream tasks now have all dependencies met If yes: INSERT downstream tasks into task_queue Exactly-Once Guarantee: Lease-based: worker gets lease (30s), must renew; if missed, task released to another worker Task execution ID: unique per attempt → DB UNIQUE constraint prevents double-insert of result Idempotent task logic: worker code must handle re-execution gracefully

Service Decomposition: Product Catalog Service → MySQL (structured) + Elasticsearch (search) + Redis (hot products) Cart Service → Redis (session-like, ephemeral, fast writes/reads) Order Service → MySQL (ACID for order lifecycle) Inventory Service → MySQL (ACID for stock counts, pessimistic lock for reserve) Pricing Service → Rules engine + dynamic pricing + Redis cache (TTL 5min) Recommendation Service → Cassandra (view/purchase history) + ML offline model Checkout Flow (Distributed Transaction — Saga): 1. Cart Service: validate cart items still available 2. Inventory Service: RESERVE stock (decrement available_count, optimistic lock on version) If stock conflict: return "out of stock", rollback reservation 3. Payment Service: charge card (idempotency key = orderId) If payment fails: compensate → Inventory Service RELEASE reservation 4. Order Service: CREATE order record with status='confirmed' 5. Inventory Service: COMMIT reservation (move from reserved → sold) 6. Kafka: OrderConfirmed → Fulfillment, Email, Analytics Inventory Concurrency (Flash Sales — 10K req/sec for 1 item): Approach 1: Redis DECR available:{productId} (optimistic, fast) Check >= 0 before decrement via Lua script (atomic) Flush to DB periodically and on order commit Approach 2: DB Pessimistic lock SELECT stock FOR UPDATE UPDATE stock SET count -= 1 WHERE id=... Safe but serialized → throughput bottleneck under high concurrency Product Search: Elasticsearch index: title, description, brand, category, attributes (faceted) Relevance: BM25 score + boost by sales rank + personalization re-rank Facets: filter by price_range, brand, rating, Prime eligibility Spell correction: fuzziness parameter in ES query Flash Sale Architecture: Pre-sale: pre-allocate tokens in Redis (1 token = 1 item reservation right) User claims token first (lottery / first-come): RPOP flash_tokens:{productId} Got token: proceed to checkout flow with guaranteed inventory Prevents overselling + reduces DB load during spike

Architecture Layers: 1. DNS + Anycast Routing: Customer's domain CNAME → cdn.example.com Anycast: same IP announced from all PoPs User's DNS query routes to geographically nearest PoP automatically GeoDNS alternative: return different IP based on user's location 2. Edge PoP (Point of Presence): Physical servers in 200+ cities, co-located in major ISPs/IXPs Local SSD cache: hot content stored on 100TB NVMe per PoP Software: Nginx/Varnish as cache layer + Envoy for load balancing TLS termination at edge (reduce round-trip latency dramatically) On cache miss: fetch from Regional Mid-tier cache or Origin Shield 3. Tiered Cache Architecture: Edge (city-level) → Regional Mid-tier (continent) → Origin Shield → Customer Origin Mid-tier collapses cache misses: 1000 edge misses → 1 request to origin Origin Shield: single PoP that faces origin (protects origin from traffic) 4. Cache Key & Invalidation: Default cache key: URL + Vary headers (Accept-Encoding, Accept-Language) Surrogate keys (cache tags): tag content by type (product:{id}) Purge by tag: invalidate all product:{12345} URLs atomically across all PoPs CDN propagates purge via gossip protocol to all edge nodes (<1s global) 5. Dynamic Content Acceleration: TLS connection maintained from edge to origin (TCP connection reuse, no handshake per user) HTTP/2 multiplexing + TCP optimization (CUBIC congestion control at edge) Route via private CDN backbone (faster + more reliable than public internet) Argo Smart Routing (Cloudflare): real-time network monitoring picks fastest path 6. DDoS Mitigation: Volumetric (L3/L4): BGP blackhole + traffic scrubbing centers absorb floods Application (L7): rate limiting per IP, WAF rules (block SQLi, bad bots) Anycast absorbs UDP floods: traffic spread across all PoPs, no single point overwhelmed Challenge pages: JS challenge / CAPTCHA for suspicious IPs

Architecture: Collection (Push vs Pull): Pull model (Prometheus): scrape /metrics endpoint of each service every 15s Pros: service doesn't need to know about monitoring infra Cons: requires service discovery, misses very short-lived processes Push model (StatsD, CloudWatch Agent): Service pushes metrics to aggregation agent Better for serverless/ephemeral functions Ingestion Pipeline (1M metrics/sec): Services → Kafka (metrics-raw topic, partitioned by service_name) Stream processor (Flink): aggregate raw points → 1-min rollups → 5-min rollups Write to TSDB (Time-Series DB) Storage — Time-Series Database: Data shape: (metric_name, labels, timestamp, value) E.g.: {name: "http_requests_total", labels: {service:"api", status:"200"}, ts: 1715000000, val: 1234.5} Options: Prometheus TSDB: local disk, chunks stored as compressed delta encoding InfluxDB: purpose-built, tag-based indexing, Flux query language Thanos / Cortex (Prometheus at scale): add S3 for long-term storage, global query Compression trick: store delta-of-deltas for timestamps + XOR compression for values Gorilla encoding (Facebook): 1.37 bytes/data point (vs 16 bytes raw) Query Layer: PromQL: rate(http_requests_total{status="500"}[5m]) → 5-min error rate Pre-computed rollups: 1s → 1min → 5min → 1hr aggregates for fast dashboard queries Cache query results in Redis (30s TTL) for popular dashboard queries Alerting: Alertmanager: evaluate alert rules every 15s against recent metrics Alert: http_error_rate > 0.01 for 5m → fire PagerDuty/Slack Deduplication: group related alerts, suppress flapping (pending state buffer) On-call routing: team owns service → route to that team's PagerDuty schedule