ML system design

Designing the system around a model: what to predict, from which features, trained how often, served under what latency, and measured against which business outcome. The model is one component of it, and usually not the hard one.

What the field actually builds

The one empirical source here is a catalog of 300+ production case studies from 80+ companies ml-system-design-case-studies. Its recurring problems are narrow and repeat across industries: recommendation and personalization (Netflix, Pinterest, Spotify), fraud and risk (Stripe, PayPal, Nubank), logistics and ETA prediction (Uber, DoorDash, Swiggy), and search and ranking (LinkedIn, Etsy, Zillow).

Ranking, matching and forecasting over behavioural data — that is what shipped, in the sectors where a small accuracy gain pays out immediately. It is a description of the written-up corpus rather than a census of the field, and the two are easy to confuse.

Design, not operation

The boundary with ../platform-ops-wiki is worth stating: that spoke owns operating production distributed systems — SRE, observability, incident response, the reliability of the thing once it runs. This page owns the design decision — the choice of target, features, model and serving shape. A feature pipeline’s uptime is ops; what the feature is, is here.

What the corpus can’t tell you

Every entry in the catalog is a company writing about a system that worked. The failures are absent by construction, and demo-to-production-gap is where the other half of the record would sit — currently held by a single unread headline ai-projects-fail-infrastructure-people. Until a source measures failure rather than asserting it, this wiki knows what succeeds and not how often.

Related

ml-system-design-case-studies · demo-to-production-gap · machine-learning · synthesis