Loading…
Compiling brilliance
Did you know? An LRU cache is a HashMap + a doubly-linked list → O(1) get & put.
Compiling brilliance
Did you know? An LRU cache is a HashMap + a doubly-linked list → O(1) get & put.
Tag
35 articles tagged hld.
How a streaming service prepares video: splitting a master into segments, fanning out parallel transcode jobs across a segment-by-rendition matrix, progressive playability, and serving from the edge.
How a mentorship platform like Preplaced matches people: hard filters that remove the unqualified, a weighted skill-overlap score that ranks the rest, and the search-match-book architecture.
How a creator-session platform works inside: turning availability windows into bookable slots, the interval-overlap test that prevents double-booking, and the hold-pay-confirm flow.
How a crypto exchange tracks money correctly: a double-entry ledger where balanced transactions conserve value, overdrafts are impossible, plus hot/cold wallet custody and the deposit/withdraw flow.
How a secure tunneling service works inside: the reverse tunnel that needs no open firewall port, stream multiplexing many requests over one connection, and subdomain routing at the edge.
How Google Docs lets many people edit one document at once: why naive concurrent edits diverge, how Operational Transformation rewrites operations to converge, and the central-server OT architecture.
How an email service works inside: accept-fast ingestion, the shared message store plus per-user mailbox index, conversation threading by reply headers with union-find, and per-user search.
How a voice assistant works inside: the wake-word-to-speech pipeline, the NLU layer that resolves an utterance to an intent and slots, the thin-device cloud-brain split, and the skill fan-out.
How a serverless platform works inside: the invocation path, cold versus warm starts, the scheduler that reuses execution environments, concurrency-limited autoscaling, and where latency goes.
How a write-optimized NoSQL store works inside: the LSM tree (memtable, write-ahead log, immutable SSTables), the read path with bloom filters, compaction and tombstones, and LSM versus B-tree.
A LinkedIn system design: the connection graph, degrees of separation via BFS, People You May Know ranked by mutual connections, why deep traversal is precomputed, and scaling the graph.
A Tinder system design: mutual-match detection that fires exactly once, the recommendation deck from a geospatial index, the swipe write firehose, privacy of one-sided likes, and scaling.
A Zoom / video-conferencing system design: mesh vs SFU vs MCU topologies, an SFU that uploads once and fans out, simulcast layer selection, signaling vs media, NAT traversal, and scaling rooms.
A file sync system design (Dropbox / Drive): content-addressed chunks with dedup, delta sync that uploads only changed chunks, the metadata-vs-block split, and conflict handling.
An AWS S3 system design: a flat bucket/key namespace, durability via erasure coding across AZs, the metadata index mapping keys to shards, multipart upload, and how object storage scales.
A load balancer system design: balancing algorithms (round-robin, least-connections, consistent hashing), health checks, L4 vs L7, and keeping the balancer itself from being a single point of failure.
A Google Maps system design: modelling roads as a weighted graph, A* routing with an admissible heuristic, precomputation for continent scale, live-traffic edge weights, and map tiles.
A WhatsApp / chat-at-scale system design: persistent connections and a routing registry, store-and-forward for offline users, idempotent ordered delivery, and the delivery-tick receipts.
A real-time collaborative editor design (CodePair / Google Docs-style): a sequence CRDT with fractional positions, converging concurrent edits over WebSockets, presence, and per-room scaling.
A BitTorrent system design: splitting a file into hashed pieces, the peer swarm and tracker, rarest-first piece selection, tit-for-tat incentives, and why P2P scales up as demand grows.
A stock exchange system design (Zerodha): a limit order book with price-time priority, the matching algorithm, an in-memory engine kept durable by a journal, and correctness over availability.
An Amazon system design on the always-available shopping cart: AP over CP, a Dynamo-style replicated key-value store, quorums, consistent hashing, and merging divergent carts.
An Airbnb / OYO system design: geospatial search with geohash prefixes, date-range availability, booking without double-booking, the data model, and scaling location search.
A database deep dive on modelling Google Calendar: storing a recurrence rule instead of infinite instances, expanding on read, cancellations and overrides, timezones/DST, and time-range queries.
A Spotify system design: storing audio as a chunked bitrate ladder in object storage behind a CDN, adaptive bitrate selection from bandwidth and buffer, the metadata model, and play history at scale.
A Stack Overflow system design: full-text search via an inverted index ranked by TF-IDF and votes, a read-heavy cache/CDN path, the Q&A data model, and keeping search in sync with the source of truth.
A live cricket score system design (Cricinfo-style): read fan-out to tens of millions, collapsing a hot key with caching and single-flight, push vs poll delivery, and freshness over consistency.
A database deep dive on modelling Reddit-style threaded comments in SQL: adjacency list vs materialized path vs closure table, fetching a subtree in one query, plus scores and sharding by post.
A newsletter service system design: fan a campaign out to millions of subscribers, the send-log idempotency key that stops double-sends, plus deliverability, retries, and open/click tracking.
An ad click event aggregation system design (HLD): tumbling windows, exactly-once counting by dedup, the Count-Min Sketch for fixed-memory counts, and stream processing with a batch recompute.
A real-time leaderboard system design (HLD): why top-N is easy but a single player's rank is hard, the sorted set and order-statistics that make rank O(log n), time windows, and the hot-key at scale.
A Twitter / X news feed system design (HLD): fan-out on write vs read, the celebrity problem, the push-pull hybrid, and assembling a timeline by merging K sorted streams at scale.
A ride sharing system design (Uber/Ola-style): the geospatial cell index that finds nearby drivers fast, the driver offer as a hold with a TTL, the double-match race, and surviving a hot region.
A movie ticket booking system design (BookMyShow-style): the data model, a seat-hold with a TTL, stopping double-booking with an atomic update, and idempotent payment at scale.
How to approach any high-level design interview: extract the data model and APIs from plain sentences — nouns, verbs, hidden tables — applied live to a Zomato-style food delivery system design.