Design Visual Search

Hard45 min
1 / 30
understanding6 min read

Problem Statement & Context

How Problem Statement & Context shapes visual search architecture for e-commerce.

Problem Statement & Context

Visual search lets a shopper photograph or upload an image and get back visually similar, purchasable SKUs in sub-second time — the capability Pinterest Lens, Amazon StyleSnap, Google Lens, and Alibaba's Pailitao popularized. The shopper has no words for what they want ("that mid-century armchair," "those boots") but they have a picture, and the system's job is to turn that picture into a ranked set of buyable products.

The mechanics, end to end: the uploaded bytes land in object storage behind a virus/safe-content gate; a preprocessor normalizes the image (cap the long edge at ~1024 px, strip EXIF GPS for privacy, optionally crop to the salient object so the embedding focuses on the garment, not the bedroom behind it); an embedder turns the image into a unit-normalized 512-dimensional vector; an approximate-nearest-neighbor (ANN) layer finds the catalog vectors closest by cosine similarity; and a business re-ranker reorders the top candidates by inventory, margin, and diversity. The scale anchors that shape the design: ~12M visual searches/day (~140 RPS mean, ~420 RPS at a 3× peak), a p99 of ~400 ms end-to-end (the upload ACK budgeted separately at ~150 ms), and an offline quality bar of Recall@50 ≥ 0.92 before any new embedding model ships.

The defining tension is visual similarity vs commercial relevance: the closest-looking product is not always the one the business should surface (it may be out of stock, low-margin, or a near-duplicate of three others). So visual search is never pure nearest-neighbor — it is retrieve-by-vision then re-rank-by-business. The failure to avoid from the start is framing this as "AI magic"; the answer anchors to measurable outcomes (recall, latency, conversion) and treats the embedding model as one swappable component behind a versioned index, not the whole system.

Key Highlights

  • Visual search: shopper photographs an item -> visually similar purchasable SKUs sub-second (Pinterest Lens / Amazon StyleSnap / Google Lens / Pailitao class)
  • Pipeline: object storage + safe-content gate -> preprocess (1024px cap, strip EXIF GPS, saliency crop) -> 512-d unit-normalized embedding -> cosine ANN -> business re-rank by inventory/margin/diversity
  • Scale: ~12M searches/day (~420 RPS peak), p99 ~400ms end-to-end, Recall@50 >= 0.92 before shipping a new embedding model; the core tension is visual similarity vs commercial relevance
Say the SLO
Tie Problem Statement & Context to p99 latency and recall@K, not model architecture buzzwords.
Skipping moderation
User uploads require NSFW and malware gates before GPU inference.
Hash dedupe
Perceptual hash cache avoids re-embedding identical Pinterest pins.

Section Rescue Kit

Buzzwords to use:

Approximate Nearest NeighborCLIP embedding

Safe statements:

  • "Multiple valid stacks—I'll compare recall vs COGS"
  • "I'd prototype with managed vector DB then optimize"
Design Visual Search - System Design | WinJob | WinJob