Real-World Case Studies

System design interviews rarely ask you to reproduce production systems verbatim. They test whether you can clarify requirements, estimate scale, draw a coherent architecture, and reason about failure modes. These eight problems cover the majority of pattern combinations you'll encounter: read-heavy caching, write-heavy fan-out, geospatial indexing, stream processing, distributed consensus trade-offs, and CDN delivery.

Functional requirements

• Create short URL — given a long URL, return a unique short code (custom alias optional for premium users)
• Redirect — GET /{shortCode} resolves to original URL via HTTP redirect
• Analytics (optional) — track clicks: timestamp, referrer, geo, user-agent
• Expiration — TTL on links; soft-delete vs hard-delete policy
• Custom aliases — user-chosen codes with uniqueness check

Non-functional requirements

Scale estimation

High-level architecture

flowchart TB
  Client[Client / Browser]
  LB[Load Balancer]
  API[Redirect Service]
  Create[Create Service]
  Redis[(Redis Cache\nshortCode → longURL)]
  MySQL[(MySQL\nsource of truth)]
  Kafka[Kafka\nclick events]
  Analytics[Analytics Pipeline\nFlink → ClickHouse]

  Client -->|GET /abc123| LB --> API
  API --> Redis
  Redis -->|miss| MySQL
  API -->|async| Kafka
  Client -->|POST /shorten| LB --> Create
  Create --> MySQL
  Create --> Redis
  Kafka --> Analytics

ID generation strategies

L5 Production choice for bit.ly-style systems: Snowflake IDs encoded in Base62 for distributed creation, with MySQL as source of truth and Redis cache-aside on read. Base62 uses [a-zA-Z0-9] — 7 chars = 62⁷ ≈ 3.5 trillion unique codes.

# Base62 encode — 7 chars covers 3.5T IDs
ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

def encode_base62(num: int) -> str:
    if num == 0:
        return ALPHABET[0]
    chars = []
    while num:
        num, rem = divmod(num, 62)
        chars.append(ALPHABET[rem])
    return "".join(reversed(chars))

# Snowflake: 41-bit timestamp | 10-bit machine | 12-bit sequence
# → ~4096 IDs/ms per machine, sortable, no DB round-trip

301 vs 302 redirect — deep dive

This is the most common L4 trap question. The choice affects SEO, analytics accuracy, and cache behavior.

MySQL + Redis read path

1. GET shortCode from Redis (short:abc123 → longURL)
2. On miss: query MySQL by primary key (short_code indexed), populate Redis with TTL (24h–7d)
3. Return 302 redirect; fire-and-forget click event to Kafka
4. On create: INSERT MySQL, SET Redis, return short URL

MySQL schema: short_code VARCHAR(10) PK, long_url TEXT, user_id, created_at, expires_at, click_count BIGINT (approximate via periodic flush from analytics). Shard MySQL by hash(short_code) when write QPS exceeds single-node capacity (~10K/sec sustained writes).

Analytics via Kafka

sequenceDiagram
  participant Redirect as Redirect Service
  participant Kafka as Kafka
  participant Flink as Flink / Spark
  participant CH as ClickHouse
  participant Dash as Analytics Dashboard

  Redirect->>Kafka: click event (async, non-blocking)
  Note over Redirect: never wait for analytics
  Kafka->>Flink: stream aggregate
  Flink->>CH: hourly rollups
  CH->>Dash: query p99 < 2s

Click events: { short_code, timestamp, ip, user_agent, referrer, geo }. Partition Kafka by short_code for ordered per-link aggregation. Never block redirect on analytics write — if Kafka is down, sample/drop events rather than fail redirects.

Functional requirements

• Limit requests per user, IP, API key, or endpoint
• Return 429 Too Many Requests with Retry-After header when exceeded
• Support multiple tiers: free (100/min), pro (10K/min), enterprise (custom)
• Configurable limits per route (POST /upload stricter than GET /health)
• Whitelist/blacklist bypass rules

Non-functional requirements & scale

Algorithm comparison

flowchart LR
  subgraph tb [Token Bucket]
    Refill[Refill 10/sec] --> Bucket[(Bucket\ncapacity 100)]
    Req1[Request] -->|take 1 token| Bucket
    Bucket -->|tokens > 0| Allow[Allow]
    Bucket -->|empty| Deny429[429 Deny]
  end
  subgraph lb [Leaky Bucket]
    In[Incoming burst] --> Queue[(Queue)]
    Queue -->|leak 10/sec| Out[Steady output]
  end

Token bucket — deep dive

Each client has a bucket with capacity B and refill rate R tokens/sec. On request: if tokens ≥ 1, decrement and allow; else reject with 429. Allows bursts up to B while maintaining average rate R over time. Used by AWS API Gateway, Stripe, and most SaaS APIs.

-- Redis Lua: atomic token bucket (EVAL script)
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local data = redis.call('HMGET', key, 'tokens', 'last_refill')
local tokens = tonumber(data[1]) or capacity
local last = tonumber(data[2]) or now

local elapsed = math.max(0, now - last)
tokens = math.min(capacity, tokens + elapsed * rate)

if tokens >= requested then
  tokens = tokens - requested
  redis.call('HMSET', key, 'tokens', tokens, 'last_refill', now)
  redis.call('EXPIRE', key, math.ceil(capacity / rate) + 1)
  return 1  -- allowed
else
  return 0  -- denied
end

Sliding window — deep dive

Fixed window allows 2× burst at minute boundaries (59 requests at 00:59 + 60 at 01:00 = 119 in 2 seconds). Sliding window counter fixes this with O(1) memory:

count = prev_window_count × (1 - elapsed/window) + curr_window_count

Store two counters per key: current and previous window. Redis key: ratelimit:{user}:{window_id}. Accuracy ~99%; used by Cloudflare and Kong gateway at scale.

Distributed rate limiting

flowchart TB
  Client --> Edge[Edge / CDN\n coarse IP limits]
  Edge --> GW[API Gateway\n per-key limits]
  GW --> Local[Local token bucket\n 80% decisions]
  Local -->|sync every 100ms| Redis[(Redis Cluster\n global truth)]
  GW --> Service[Microservice]
  Service -->|optional 2nd check| Redis

• Centralized (Redis) — accurate global limits; adds ~0.5–1 ms latency; single cluster is bottleneck
• Local + sync — each node holds local bucket, syncs quota to Redis periodically; faster but briefly over-limit during sync
• Edge limiting — Cloudflare/Kong at PoP; stops abuse before origin; coarse granularity (IP/CIDR)
• Consistent hashing — route same user to same Redis shard; avoids cross-shard coordination

Functional requirements

• put(key, value) — store arbitrary blob (≤ 1 MB per value typical)
• get(key) — retrieve latest value or not-found
• delete(key) — tombstone for eventual removal
• Optional: conditional writes (put if not exists), TTL expiration
• No complex queries — point lookups only (by design)

Non-functional requirements

High-level architecture

flowchart TB
  Client[Client SDK]
  Coord[Coordinator / Router]
  subgraph ring [Consistent Hash Ring]
    N1[Node A\nvnodes 0-85]
    N2[Node B\nvnodes 86-170]
    N3[Node C\nvnodes 171-255]
  end
  subgraph nodeA [Each Storage Node]
    HT[(In-memory\nHash Table)]
    WAL[(Write-Ahead Log)]
    SST[(SSTable / Disk)]
    HT --> WAL --> SST
  end
  Client --> Coord --> ring
  N1 --> nodeA

In-memory hash table — deep dive

Hot data lives in an in-memory hash map (open addressing or chained buckets). Each entry: { key, value, version, expiry }. Memory budget: if node has 64 GB RAM, reserve ~48 GB for hash table, rest for buffers/OS. Eviction: LRU for cache tier; for durable store, flush cold entries to SSTable on disk.

Write-Ahead Log (WAL) — deep dive

Every write appends to WAL before acknowledging the client. On crash recovery: replay WAL to rebuild in-memory state. WAL segment rotation: new file every 64–128 MB; old segments deleted after SSTable flush.

1. Client sends PUT
2. Append (key, value, seq, timestamp) to WAL (fsync or group commit batch)
3. Update in-memory hash table
4. Replicate to N-1 nodes (async or sync per consistency level)
5. Return success to client

Replication & quorum

Each key maps to a preference list of N nodes (typically N=3) via consistent hashing. Coordinator sends write to all N replicas; read from R replicas.

sequenceDiagram
  participant C as Client
  participant Co as Coordinator
  participant R1 as Replica 1
  participant R2 as Replica 2
  participant R3 as Replica 3

  C->>Co: PUT key (W=2)
  Co->>R1: write v5
  Co->>R2: write v5
  Co->>R3: write v5 (async)
  R1-->>Co: ack
  R2-->>Co: ack
  Co-->>C: success (2 of 3)

  C->>Co: GET key (R=2)
  Co->>R1: read
  Co->>R2: read
  Co-->>C: return max version

Consistent hashing — deep dive

Place nodes and keys on a hash ring (0 to 2³²-1). Key maps to first node clockwise on ring. Virtual nodes: each physical node owns 100–256 vnodes for even load distribution. Adding a node: only adjacent key ranges migrate (~K/N keys).

Failure handling

• Hinted handoff — if preferred node down, write to next node on ring; return when original recovers
• Read repair — on read, if replicas disagree, write latest version to stale replicas
• Anti-entropy — background Merkle tree comparison between replicas; sync divergent keys
• Gossip membership — nodes discover failures via SWIM protocol; update ring state

Functional requirements

• Post tweet — user publishes ≤ 280 chars (+ media metadata)
• Home timeline — paginated feed of tweets from followed users, newest first
• Follow / unfollow — update social graph
• Search & trends — trending topics (optional scope extension)
• Media — images/video stored separately; timeline holds references

Scale numbers

Fan-out on write vs fan-out on read

flowchart TB
  Post[User posts tweet]
  Post --> Check{Followers > 10K?}
  Check -->|No| FOW[Fan-out on write\npush to follower timelines]
  Check -->|Yes| Celeb[Store in celebrity bucket\nno fan-out]
  FOW --> Redis[(Redis Sorted Set\ntimeline:userId)]
  Celeb --> TweetStore[(Cassandra\ntweets by user)]
  Read[User reads timeline] --> Redis
  Read --> Merge[Merge celebrity tweets\nfrom Cassandra]
  Merge --> Response[Sorted merged feed]

Redis sorted sets — deep dive

Each user's home timeline is a Redis sorted set (ZSET): score = tweet timestamp (or snowflake ID), member = tweet_id. ZADD timeline:{userId} {timestamp} {tweetId} ZRANGE timeline:{userId} 0 49 REV → latest 50 tweets in O(log N + 50).

• Cap timeline at ~800 entries; trim oldest on insert (sliding window cache)
• 800 × 8 bytes tweet_id × 300M users = ~192 GB if every user had full cache — most inactive; use tiered storage
• Hot users' timelines in Redis; cold users fan-out-on-read from Cassandra

Cassandra for tweet storage

Partition key design drives everything:

The celebrity problem — deep dive

Katy Perry (~100M+ followers): one tweet = 100M Redis ZADD operations. At 1 ms each (absurdly optimistic), that's 27+ hours. Even at 100K ops/sec cluster-wide, one celebrity tweet consumes the entire cluster for 1000 seconds.

Solution — hybrid fan-out:

1. Users with <10K followers: fan-out on write to Redis timelines
2. Celebrities (>10K): tweet stored only in their Cassandra partition
3. On timeline read: fetch precomputed timeline + fetch recent tweets from each followed celebrity + merge sort
4. Cache merged celebrity slice separately (5–30 sec TTL)

Trends — HyperLogLog

Counting unique users per hashtag at Twitter scale is impossible with exact counters. HyperLogLog in Redis: ~12 KB memory per key, ~0.81% error, counts billions of uniques. Pipeline: tweet → Kafka → Flink extracts hashtags → PFADD trend:{hashtag} {userId} → periodic PFCOUNT for ranking. Top-K via Count-Min Sketch + heap.

Functional requirements

• Upload video — resumable upload, metadata (title, description, tags)
• Transcode — multiple resolutions (360p–4K) and formats (H.264, VP9, AV1)
• Stream — adaptive bitrate playback with low startup latency (<2 sec)
• Search & recommendations — home feed, related videos
• Analytics — view counts, watch time, creator dashboard

Scale numbers

Upload pipeline

flowchart LR
  Creator[Creator App]
  Upload[Upload Service\nresumable chunks]
  Blob[(Object Storage\nS3 / GCS)]
  Meta[(Metadata DB\nvideo_id, status)]
  Queue[SQS / Pub-Sub]
  Transcode[Transcoding Farm\nFFmpeg workers]
  CDN[CDN Origin]
  Catalog[Catalog Service]

  Creator -->|chunked PUT| Upload
  Upload --> Blob
  Upload --> Meta
  Upload -->|video.uploaded| Queue
  Queue --> Transcode
  Transcode -->|read raw| Blob
  Transcode -->|write HLS segments| CDN
  Transcode --> Meta
  Meta --> Catalog

Resumable upload — deep dive

1. Client requests upload session → server returns upload_id + signed chunk URLs
2. Upload 5–50 MB chunks with Content-Range headers
3. Server tracks received byte ranges in Redis/DB
4. On disconnect: client resumes from last confirmed byte
5. Complete: assemble manifest, trigger transcoding job

YouTube uses resumable HTTP uploads (similar to Google Cloud Storage protocol). Never hold full video in app server memory.

Transcoding with FFmpeg — deep dive

Transcoding farm: Kubernetes jobs, one FFmpeg process per job, GPU nodes for 4K/AV1. Priority queue: popular creators / live replay first. Spot/preemptible instances for 70% cost savings. Output: HLS (.m3u8 manifest + .ts segments) and DASH (.mpd + .m4s) for browser compatibility.

# FFmpeg: generate HLS ladder from source
ffmpeg -i input.mp4 \
  -filter_complex "[0:v]split=3[v1][v2][v3]; \
    [v1]scale=640:360[v1out]; [v2]scale=1280:720[v2out]; [v3]scale=1920:1080[v3out]" \
  -map "[v1out]" -c:v libx264 -b:v 800k -map a:0 -c:a aac -b:a 96k -f hls stream_360.m3u8 \
  -map "[v2out]" -c:v libx264 -b:v 2500k -map a:0 -c:a aac -b:a 128k -f hls stream_720.m3u8 \
  -map "[v3out]" -c:v libx264 -b:v 5000k -map a:0 -c:a aac -b:a 192k -f hls stream_1080.m3u8

CDN & HLS/DASH delivery

sequenceDiagram
  participant Player
  participant CDN as CDN Edge
  participant Origin as Origin / Storage

  Player->>CDN: GET master.m3u8
  CDN-->>Player: 360p/720p/1080p variants
  Player->>Player: measure bandwidth
  Player->>CDN: GET 720p segment 001.ts
  CDN-->>Player: video chunk
  Note over Player: switch to 1080p if bandwidth allows
  Player->>CDN: GET 1080p segment 002.ts
  CDN->>Origin: cache miss fetch
  Origin-->>CDN: segment
  CDN-->>Player: video chunk

Adaptive bitrate (ABR): player monitors buffer and bandwidth, switches quality per segment. CDN caching: popular videos cached at edge; long-tail served from origin. Cache key: video_id + resolution + segment_index. Immutable segments = infinite TTL.

Recommendations — deep dive

• Candidate generation — collaborative filtering, content similarity, subscribed channels (millions → hundreds)
• Ranking — ML model scores candidates on watch probability, satisfaction, diversity
• Two-tower model — user embedding × video embedding dot product for fast retrieval at scale
• Feature store — real-time features (last 10 watches) + batch features (user demographics)
• Freshness — new uploads indexed within minutes via stream processing

Functional requirements

• Request ride — rider specifies pickup, dropoff, ride type
• Match driver — find available driver within ~3 km, ETA < 5 min
• Track trip — real-time location updates for rider and driver
• Surge pricing — dynamic multiplier when demand exceeds supply
• Payment & receipt — charge on trip completion
• Rating — post-trip feedback

Scale numbers

High-level architecture

flowchart TB
  Rider[Rider App]
  Driver[Driver App]
  GW[API Gateway]
  Trip[Trip Service\nstate machine]
  Match[Matching Service]
  Geo[(Geospatial Index\nRedis GEO / H3)]
  Surge[Surge Service]
  Loc[Location Service]
  Pay[Payment Service]
  WS[WebSocket / Push]

  Rider --> GW --> Trip
  Trip --> Match
  Match --> Geo
  Match --> Surge
  Driver -->|GPS every 4s| Loc --> Geo
  Trip --> WS
  WS --> Rider
  WS --> Driver
  Trip --> Pay

Geospatial indexing — deep dive

Redis GEO for hot path: GEOADD drivers:{cityId} {lng} {lat} {driverId}, GEORADIUS drivers:{cityId} {lng} {lat} 3 km COUNT 10 ASC. Partition by city/region — NYC, SF, London each own Redis cluster shard. Driver location updates every 3–4 seconds; stale drivers (>30 sec) excluded from matching.

H3 & surge pricing — deep dive

Uber open-sourced H3 — hexagonal hierarchical geospatial index. Resolution 7 hex ≈ 1.2 km²; resolution 9 ≈ 0.1 km². Surge computed per H3 cell: surge = demand / supply smoothed over 5-min window.

1. Count ride requests per H3 cell (demand signal)
2. Count available drivers per H3 cell (supply signal)
3. If ratio > threshold (e.g., 2.0): surge multiplier = min(ratio, 3.0)
4. Push surge map to rider app via WebSocket; refresh every 60 sec
5. Drivers incentivized to move to high-surge hexes (supply rebalancing)

Trip state machine

stateDiagram-v2
  [*] --> Requested: rider requests
  Requested --> Matching: find drivers
  Matching --> Accepted: driver accepts
  Matching --> Cancelled: no driver / timeout
  Accepted --> Arriving: driver en route
  Arriving --> InProgress: rider picked up
  InProgress --> Completed: dropped off
  InProgress --> Cancelled: mid-trip cancel
  Completed --> Paid: payment processed
  Paid --> [*]
  Cancelled --> [*]

State stored in Trip Service (PostgreSQL or DynamoDB). Each transition emits domain event to Kafka: trip.accepted, trip.completed. Payment, notification, and analytics services subscribe. Idempotency keys on transitions prevent double-charge on retry.

Matching algorithm

• Fetch top 10 nearest available drivers (GEORADIUS ASC)
• Filter: correct ride type, rating > 4.5, not on another trip
• Score: ETA (60%) + driver acceptance rate (20%) + direction of travel (20%)
• Dispatch to best driver; if no accept in 15 sec, offer to next
• Batch matching in dense areas: solve assignment problem (Hungarian algorithm) every 2 sec

Functional requirements

• Send message — text, image, video, voice note to individual or group (≤1024 members)
• Delivery receipts — sent ✓, delivered ✓✓, read (blue ✓✓)
• Offline delivery — store-and-forward when recipient offline
• E2E encryption — server cannot read message content
• Last seen / online status — privacy-controlled presence
• Multi-device sync — same account on phone + desktop

Scale numbers

High-level architecture

flowchart TB
  Sender[Sender Device]
  ConnGW[Connection Gateway\n500M WebSockets]
  MsgSvc[Message Service]
  Router[User Router\nuser_id → server]
  Cassandra[(Cassandra\nmessage store)]
  Offline[(Offline Queue\nper user partition)]
  Push[Push Notification\nAPNs / FCM]
  Receiver[Receiver Device]
  Media[(Object Storage\nencrypted blobs)]
  Signal[Signal Protocol\nE2E layer]

  Sender -->|encrypted payload| ConnGW --> MsgSvc
  MsgSvc --> Router
  Router -->|online| ConnGW --> Receiver
  Router -->|offline| Offline
  MsgSvc --> Cassandra
  Offline --> Push
  Sender --> Media
  Signal -.->|keys on device| Sender
  Signal -.->|keys on device| Receiver

Cassandra message storage — deep dive

Partition key = conversation_id (or recipient_user_id for 1:1).

WhatsApp famously uses Erlang for connection handling (soft real-time, millions of processes) and FreeBSD tuning. Message metadata in Cassandra; content is encrypted blob the server cannot decrypt. Groups: fan-out on write to each member's offline queue (similar to Twitter, but encrypted envelope per recipient).

Delivery receipts — deep dive

sequenceDiagram
  participant S as Sender
  participant Server
  participant R as Receiver

  S->>Server: send encrypted msg (msg_id)
  Server-->>S: ack sent (1 grey tick)
  Server->>R: push message
  R->>Server: ack received
  Server-->>S: delivered (2 grey ticks)
  R->>R: user opens chat
  R->>Server: ack read
  Server-->>S: read (2 blue ticks)

Receipts are lightweight control messages (~50 bytes), not full message re-transmission. Stored in Cassandra with TTL; aggregated for group chats (delivered when all members ack). Ordering: server-assigned monotonic message_id per conversation (not wall clock — avoids clock skew).

E2E encryption — Signal Protocol

• X3DH — extended triple Diffie-Hellman for initial key agreement (first message to new contact)
• Double Ratchet — forward secrecy: compromise of current key doesn't expose past messages
• Sender Keys — for group messages: one encrypted payload, per-member keys for fan-out efficiency
• Server stores only: { from, to, timestamp, encrypted_blob, msg_id } — no plaintext ever
• Key transparency: safety numbers for verifying contact identity

Connection layer at 500M concurrent

• Connection gateway shards by user_id hash — sticky routing to same Erlang node
• Heartbeat every 30 sec; disconnect after 3 missed → mark offline, route to push
• Long-poll fallback for restrictive networks (HTTP/2 multiplexing)
• Cross-region: user homed in primary region; travel = cross-region relay with +50 ms latency acceptable for async chat

Functional requirements

• Map display — pan, zoom, satellite/terrain layers at 60 fps
• Route planning — origin → destination, multiple waypoints, avoid tolls/highways
• Turn-by-turn navigation — real-time rerouting on deviation or traffic change
• ETA — accurate arrival time using live traffic
• Search — places, addresses, POI autocomplete
• Traffic overlay — color-coded congestion on map

Scale numbers

High-level architecture

flowchart TB
  Client[Mobile / Web Client]
  CDN[CDN\nmap tiles]
  TileSvc[Tile Server\n256×256 PNG/vector]
  RouteAPI[Routing API]
  CH[Contraction Hierarchies\npreprocessed graph]
  Traffic[Traffic Service\nreal-time speeds]
  Graph[(Road Graph Store)]
  Probe[Probe Ingestion\nKafka]
  Search[Places Search\nElasticsearch]
  ETA[ETA ML Model]

  Client --> CDN
  Client --> RouteAPI
  CDN -->|miss| TileSvc
  RouteAPI --> CH
  RouteAPI --> Traffic
  CH --> Graph
  Traffic --> Probe
  Traffic --> ETA
  Client --> Search

Map tiles — deep dive

World divided into zoom levels 0–22. At zoom Z, earth split into 4^Z tiles. Each tile: 256×256 pixels (raster PNG) or vector (Mapbox Vector Tiles / protobuf).

Tile URL pattern: /tiles/{z}/{x}/{y}.pbf. CDN serves 99%+ from edge. Traffic overlay is a separate transparent tile layer refreshed every 2–5 minutes — not baked into base map.

Graph routing — deep dive

Road network = weighted directed graph: nodes = intersections, edges = road segments, weight = travel time. Naive Dijkstra on 200M nodes: O(E log V) → seconds to minutes. Unacceptable for interactive routing.

Contraction Hierarchies (CH)

Preprocess graph offline: iteratively contract least-important nodes, adding shortcut edges that preserve shortest paths. Result: hierarchy where upward search from source and downward search from target meet in middle — explored nodes drop from millions to thousands.

• Preprocessing: hours on cluster for continent-sized graph; rerun weekly or on map update
• Query: bidirectional search on hierarchy → <100 ms on continental graph
• Memory: ~10–20× original graph size with shortcuts (acceptable for in-memory serving)
• Dynamic traffic: edge weights updated from traffic service; CH structure unchanged, weights hot-reloaded

flowchart TB
  subgraph preprocess [Offline Preprocessing]
    Raw[Raw road graph\n200M nodes] --> Contract[Iterative contraction\nadd shortcuts]
    Contract --> CHGraph[CH Graph\nin memory]
  end
  subgraph query [Online Query — sub 100ms]
    Src[Source] --> Up[Upward search\nin hierarchy]
    Tgt[Target] --> Down[Downward search\nin hierarchy]
    Up --> Meet[Meet at node]
    Down --> Meet
    Meet --> Path[Unwrap shortcuts\nfull route]
  end
  CHGraph --> query

Real-time traffic — deep dive

1. Probe ingestion: anonymized GPS speed from Android/iOS Maps users → Kafka (billions/day)
2. Aggregation: Flink windows compute median speed per road segment (edge) per 2-min bucket
3. Weight update: travel_time = segment_length / max(median_speed, 5 km/h)
4. Push to routing: in-memory edge weight table refreshed every 2–5 min
5. ETA ML: gradient-boosted model on historical + live traffic + time-of-day + weather

Alternative algorithms (know for L6)