Design Personalization Engine

Problem Statement: Omnichannel Personalization Engine

A personalization engine decides what each user sees across every surface — home feed, category rails, email, push, and in-app modules — and it is broader than product recommendations: layout slots, message copy, offer depth, and business rules all compete for the same scarce user-attention budget. The unifying architecture, the thing the interviewer wants you to name, is the retrieve -> rank -> policy pipeline with consent-first defaults: generate candidates, score them, then apply business and compliance rules before rendering.

The engine is the shared ranking fabric beneath many surfaces — Netflix ranks rows, Spotify ranks playlists (Discover Weekly is a batch-plus-online blend), and Amazon's home page ranks every widget, each widget calling the same orchestrator with different retrieve sources and policy packs. Generalizing that pattern to commerce means ranking slots under inventory and margin constraints, not just predicting clicks.

The scale anchors: ~120M daily active users and ~2.8B ranked decisions/day, with a p99 serve latency of ~45ms for the home feed — which decomposes into a tight per-stage budget (retrieve ~8ms, rank ~15ms, policy ~5ms). Different surfaces have radically different budgets: home is a strict sub-50ms synchronous path, while email is a batch job that can afford a heavyweight model and pins a model-and-policy version at send time.

The failure that defines the design is the silent recall gap: ANN retrieval misses an obvious SKU the user clearly wants, which surfaces as a 'why isn't my favorite brand here' bug — invisible in aggregate CTR but corrosive to trust. You monitor it with recall@50 on golden queries per category, because a ranker can only rank what retrieval surfaced — a candidate that was never retrieved can never be shown, no matter how good the model.