Skip to content
academia.sh
tr
Log in

Course Advanced

Case Studies

By the end of this course

Start course

01

Read-Heavy Systems

Four designs where reads outnumber writes by a wide margin: a URL shortening service built on key generation, redirection, and caching; comparing fan-out on write with fan-out on read for the same stream; a search suggestion built on prefix structures and update lag; and a content distribution design that separates static from dynamic content.

  1. 01 URL Shortening Service The first read-heavy case: turning the constraints into functional and non-functional requirements as numbers, deriving a back-of-the-envelope estimate from nine assumptions, choosing the short-key length from the occupancy rate, the collision rate, and the guessing cost, eliminating counter-based generation with a measured difference, and writing down the design's behavior under a partition failure and the freshness it gives up.
  2. 02 News Feed Building the same stream with two distribution models: measuring the work volume of fan-out on write against fan-out on read, the tail of the follower distribution misleading an estimate done with the average, deriving the hybrid model's threshold as a number from the distribution capacity and the visibility window, and computing the moment the window is exceeded when the distribution consumer slows down.
  3. 03 Search Suggestion A read case where the response cannot be prepared at write time: comparing the prefix tree's memory and search cost against a flat list, choosing the tree's depth as a number from the memory budget, measuring the change update lag produces in the first ten suggestions, and a frozen structure degrading through staleness.
  4. 04 Content Distribution Design Separating static and dynamic traffic: measuring the split's effect on the request count and bytes reaching the origin with an edge cache model, deriving the hit rate the threshold requires from the estimate, separating the request hit rate from the byte hit rate, and the versioned name zeroing out the staleness window.

02

Write- and Consistency-Heavy Systems

Five cases where writing and correctness drive the design: a chat system with connection management, delivery guarantees, and ordering problems; a notification system with multi-channel distribution and retries; a rate limiter with distributed counters and window algorithms; a ticketing and inventory system with contention management under limited resources; and a payment flow built on idempotency, reconciliation, and an audit trail.

  1. 01 Chat System The first case where writing dominates: connection and delivery scale drawn from nine assumptions, the effect of the delivery guarantee choice on lost and duplicated message counts measured in a one-second peak window, ordering violations counted with inversions, the sequential convoy's cost in wait rounds, and the polling model eliminated by its breakeven interval.
  2. 02 Notification System The case where the same message can go out over more than one path: separating channel-specific transient and permanent failure rates, three attempts on a single channel leaving the delivery rate 3.01 points below the threshold, measuring single-channel against parallel and cascading channel order in delivery rate, outbound calls, duplicate deliveries, and delay, and parallel fan-out eliminated by its call amplification.
  3. 03 Rate Limiter Designing the component whose job is to reject the request: the overshoot allowed by fixed window, sliding window counter, and token bucket measured across three request patterns, the doubling crossing at the window boundary counted, the overshoot and false-rejection count the distributed counter produces under centralized, split-quota, and delayed-synchronization arrangements, and the synchronization interval determining the threshold.
  4. 04 Ticketing and Inventory System The case where the counted thing cannot be recovered: the allotment exhausting in 0.179 seconds at peak rate, the unprotected read–decide–write flow overselling the allotment by 5.59x under 16 concurrent workers, optimistic and pessimistic locking measured in oversold items versus rejected valid requests, and the reservation window's effect on wasted item-seconds.
  5. 05 Payment Flow The case where the two sides' records diverge: splitting the number of unmatched records in a reconciliation cycle by source, polling bringing the gap down from 59.74 per mille to 9.76 per mille, late-arriving confirmations making up most of the remaining gap, the cycle interval lowering the gap rate while lengthening the closure time, and the audit trail's seven-year volume.

03

Data-Intensive Systems

Five cases where the volume of data drives the design: an object storage service with multipart upload and a durability calculation, a video streaming service with a transcoding pipeline and adaptive streaming, a metrics aggregation system with a time-series write path and rollups, a location-based service with spatial indexing and proximity queries, and a batch-and-stream processing pipeline that uses both processing models together.

  1. 01 Object Storage Service The first case where volume drives the design: choosing part size against the probability of interruption, measuring the extra bytes sent in an in-process model and verifying it with a closed form, comparing replica count against erasure coding on storage factor and annual loss, and eliminating coding for small objects on request count.
  2. 02 Video Streaming Service The case where multiple representations of the same content are kept: budgeting the transcoding pipeline in processor-seconds, measuring the bitrate ladder's hit rate against the viewer bandwidth distribution, the shrinking bandwidth utilization gained per rung, and three separate constraints eliminating three separate ladders.
  3. 03 Metrics Aggregation System The case where no single record is meaningful on its own: budgeting the time-series write path by sample rate, the effect of storage tiers on total bytes, and measuring in a real engine which questions downsampling leaves untouched and which it answers with one hundred percent error.
  4. 04 Location-Based Service The case of a query with no sortable key: comparing the proximity query against a flat scan, measuring on real data the candidate count a geohash scans, choosing cell size from the trade-off between candidate count and index lookups, and counting the results missed when a neighboring cell is not queried.
  5. 05 Batch and Stream Processing Pipeline The closing case where two processing models are used together in the same system: how the watermark cuts off late-arriving data, how the stream path's first published result diverges from the batch path's recomputation, the divergence's closing curve, and the overhead cost of running both paths at once.

Start typing to search.

↑↓ ↵ Esc navigate · open · close