Design Wishlist System

Problem Statement: Wishlists and Gift Registries

A wishlist-and-registry platform lets a shopper save products for later and lets a couple or expecting parent publish a shareable list that other people buy from. Those are two products wearing one feature's clothes. A private wishlist is a personal save-for-later collection optimized for low-latency adds and reads by a single owner. A public registry — a wedding or baby-shower list — is a shared, high-fan-out read surface where dozens or hundreds of guests load the same page and a subset of them buy. Treating these as one system is the first mistake; their consistency, privacy, and traffic profiles diverge sharply.

The hardest invariant lives on the registry side: when two guests check out simultaneously for the last available unit of a gift, exactly one must succeed. A registry line is not a simple "bought" boolean — it tracks desired, purchased, and reserved quantities separately, so a couple who wants four place settings can receive partial gifts without two guests accidentally buying the same fourth one. Getting this concurrency wrong produces the embarrassing real-world failure of duplicate gifts, which is exactly what a registry exists to prevent.

The two halves also pull the architecture in different directions, and naming that split early is the senior move. Price-drop alerts are a stream problem — watch many items, fire when a price crosses a threshold, keep false positives low. Registry fulfillment is a transactional outbox problem — a checkout in the order system must update registry quantities exactly once, reliably, within a few seconds. Mixing the two, for example driving fulfillment off the same noisy price-event stream, creates false positives and lost updates. Keeping them as separate pipelines is the design's spine.

The numbers frame the rest. Assume 80 million shoppers maintaining on the order of 400 million lists and 3 billion saved line items, with peaks around 25,000 item-adds per second and 120,000 anonymous registry-page views per second when a list trends. The targets that follow: add-to-list p99 under 150 ms, public registry time-to-first-byte under 300 ms from the CDN edge, purchase-projection lag under 5 seconds, and a price-alert false-positive rate under 1%.