Systems
Real product architectures as buildable blueprints: constraints, request path, data model, storage/cache/queue choices, and what a smaller team should copy vs skip.
YouTube
Global video upload, processing, and streaming at scale
YouTube handles petabytes of video upload and billions of views daily. The architecture separates upload, async processing (transcoding to multiple resolutions), and playback via CDN-cached adaptive streaming. Storage is object-based; a metadata DB tracks videos.
Read the case studyNetflix
Streaming-first architecture with an online→nearline→offline tiering
Netflix serves video from a global CDN (its own Open Connect appliances inside ISPs) with the control plane on AWS. Viewing metadata, recommendations, and the API gateway run in the cloud; playback bytes come from edge caches close to users.
Read the case studyTwitter/X feed
Fan-out-on-write vs fan-out-on-read for a timeline
Twitter's home timeline is the classic fan-out problem. For most users, new tweets are pushed (fan-out-on-write) into precomputed timeline caches for their followers. For huge accounts (celebrities), fan-out-on-write would overwhelm, so their timelines are assembled on read by merging.
Read the case studyUber dispatch
Real-time matching of riders to nearby drivers
Uber matches riders to the nearest available drivers in seconds. The core is a geospatial index of driver locations updated constantly, a dispatch service that finds nearby cars, and a stateful trip manager. Reads dominate; location updates are high-frequency.
Read the case studyPhoto sharing with a feed and sharding by user
Instagram stores photos in object storage and metadata in a sharded PostgreSQL setup, originally sharding by user id across many instances. The feed is a reverse-chronological/precomputed timeline. Media is served via CDN; metadata via sharded DBs with caching.
Read the case studyHigh-concurrency chat with Erlang and per-group state
WhatsApp serves billions of users with a small engineering team using Erlang/BEAM, whose lightweight processes map naturally to per-user/per-group message passing. Messages are delivered via a persistent connection; offline messages are stored and pushed on reconnect.
Read the case studyStripe
Payments with idempotency, strong consistency, and double-entry ledgers
Stripe exposes payments as an API with strong consistency, idempotency keys, and a double-entry ledger per merchant. Every charge is durable and replayable; webhooks notify merchants. Correctness and auditability dominate over raw throughput.
Read the case studyDiscord
Realtime chat with Elixir and a hybrid DB/NoSQL backend
Discord serves real-time guild chat with Elixir/OTP (millions of concurrent connections), ScyllaDB for message history, and Redis for presence/sessions. Messages fan out to online members via persistent connections; history is queried from ScyllaDB.
Read the case study