Design Pinterest

Save images to boards, browse a personalised grid and search by picture: 100 M daily users, 5 B distinct images behind 100 B saves.

Last updated 2026-10-27. Difficulty: hard. Patterns: random-walks, visual-search, deduplication, vector-search, image-serving. Reported at Pinterest, Meta, Snap, Google, Amazon, Instacart.

Functional requirements

• Save a pin to a board. A pin is a save: an image, a link and a description, placed on one of your boards. Most saves re-save an image we already hold, so a save must never copy image bytes.
• Boards and follows. Create boards, follow people or single boards. Followed pins are one slice of the home feed, not the whole of it.
• Home feed. A personalised masonry grid, 25 pins a page, scrolling without end. Most pins come from people the viewer does not follow, and the grid must lay out before any image arrives.
• More like this. Open a pin and see related pins below it. The answer depends on the pin far more than on the viewer, which is what makes it cacheable.
• Text search. “brass floor lamp” finds pins whose words match, and also pins whose picture matches but whose description only says “my reading corner”.
• Visual search. Tap a detected object or draw a box on any image, or point the camera, and get visually similar pins: the lamp in someone’s living-room photo.
• New pins discoverable fast. A fresh pin shows in followers’ feeds and in search within minutes, even though the big indexes are rebuilt only daily or weekly.
• Spam and low quality kept out. Pins that link to spam, malware or cloaked pages are blocked or removed, and a removal applies under every save of the image, on every surface, within minutes.
• Out of scope. Ads, shopping catalogues and checkout, messaging, notifications, video pins (see Design YouTube) and the upload mechanics themselves (presigned direct uploads, as in Design Instagram). Models are named, not designed.

Non-functional requirements

• Scale (100 M DAU · 50 k pages/s peak). About 75 feed pages are served for every save, and ~100 B saves point at only ~5 B distinct images. Reads and reuse dominate.
• Home feed latency and availability (p99 < 300 ms · 99.95 % served). The first page of a session runs the whole candidate funnel; later pages read a cached ranked list in ~20 ms. When a source fails the page is thinner, never blank.
• Graph candidates from RAM (walk p99 < 50 ms). This drives the hardest trade-off. A random walk is tens of thousands of dependent memory reads, so the whole graph must sit in one machine’s RAM: ~100 B saves are pruned to ~20 B edges, and the graph scales by replicas, not shards.
• Visual search (p99 < 500 ms over ~10 B vectors). Raw float vectors are ~10 TB, so recall is traded against memory through quantisation, and a re-rank on full vectors wins most of it back.
• Grid lays out before images load (zero layout shift). Every pin in an API response carries its image’s width, height and dominant colour, so the client places all 25 cards and paints coloured tiles before the first image byte arrives.
• Freshness (new pin searchable < 5 min). In followers’ feeds within ~10 minutes, walkable as soon as it is re-saved, in the embedding index after the next daily build. Pins are evergreen, so a day is acceptable on the slow paths.
• Image delivery and durability (CDN hit > 97 % · no lost originals). ~2.4 PB of images a day leaves the edge. Originals are kept with object-storage durability; the fixed sizes can always be regenerated from them.
• Safety (removed pins off every surface < 5 min). A takedown or spam verdict on an image must apply to all of its saves in feeds, search, related pins and caches, not only to the pin someone reported.

Back-of-envelope estimates

• Home feed pages: ~17 k/s avg · ~50 k/s peak. 100 M DAU × 15 pages a day (25 pins each) = 1.5 B/day ÷ 86 400 ≈ 17 k/s; the evening peak runs ~3× that, ~50 k/s. Only the first page of a session runs the candidate funnel, about 1 page in 5, so ~10 k funnels a second at peak.
• Saves: ~230/s avg · ~700/s peak. 20 M saves a day ÷ 86 400 ≈ 230/s, ×3 at peak. About 90 % re-save an image we already hold, so only ~2 M a day bring new bytes. Writes are not the hard part: 75 pages are read for every save.
• Image storage: ~3 PB deduplicated (~60 PB per save). Per canonical image: an original of ~400 KB plus three fixed widths, 236 px 20 KB, 474 px 60 KB and 736 px 120 KB, ≈ 600 KB. 5 B × 600 KB = 3 PB. A copy per save would be 100 B × 600 KB = 60 PB. Growth is 2 M new images × 600 KB ≈ 1.2 TB/day, ~440 TB a year.
• CDN egress: ~2.4 PB/day · ~80 GB/s peak. Grid: 1.5 B pages × 25 pins × 60 KB (the 474 px size) ≈ 2.25 PB; close-ups: 1 B a day × 120 KB ≈ 0.12 PB. Total ~2.4 PB/day ≈ 28 GB/s on average, ~80 GB/s at peak. At a 97 % hit rate the origin still serves ~0.8 GB/s. The head is small: the top 1 % of images (50 M) × 200 KB of sizes is ~10 TB, which fits on every large PoP.
• Pin-board graph in memory: ~800 GB raw · ~185 GB pruned. 100 B save edges stored in both directions (image → boards, board → images) at 4 B per entry = 800 GB, and 7 B nodes do not even fit 32-bit ids. Pruned to ~3 B nodes and 20 B edges: 20 B × 2 × 4 B = 160 GB plus 3 B × 8 B offsets = 24 GB ≈ 185 GB, one 256 GB machine. Every graph server holds all of it.
• Walk compute: ~170 cores at peak. Walks run for ~10 k feed funnels/s plus ~7 k related-pin cache misses/s = 17 k/s. A walk of ~50 k steps at ~200 ns a step (two dependent cache misses) is ~10 ms of one core: 17 k × 10 ms = 170 cores, a handful of 64-core machines per region. The graph tier is small in machines and large in RAM per machine.
• Visual index: ~10 TB raw · ~720 GB quantised. ~5 B whole images plus ~5 B detected objects = 10 B vectors × 256 dims × 4 B = 10 TB of float32, about 80 machines of RAM for one replica. Product quantisation to 64 B plus an 8 B id = 72 B each, 720 GB: 24 shards of 30 GB in RAM, with full vectors on local NVMe for re-ranking.
• Feed cache: ~110 GB. At peak ~10 k sessions start a second, and each ranked list lives 30 minutes: 18 M live lists. 200 ranked entries × ~24 B (pin id, image id, score, source) plus a seen set ≈ 6 KB. 18 M × 6 KB ≈ 110 GB: a small Redis cluster, and all of it can be recomputed.

Components

• Pinterest app (masonry grid · web + mobile): Renders the masonry grid: it places every card from the width, height and dominant colour in the JSON before any image loads, then fills tiles from the CDN at the width its column needs. Saves pins, batches close-ups, clicks and hides as events, and runs visual search on a crop or a camera photo.
• Image CDN (fixed widths · immutable URLs): Serves every image byte, ~2.4 PB a day. URLs carry the canonical image id and a fixed width (236, 474 or 736 px, or the original), so they never change and cache for a year. Deduplication pays off here too: an image saved 100,000 times is one URL and one cache entry, not 100,000. Misses go through a regional shield that coalesces them before object storage.
• Pin service (saves · boards · events): The write API behind the gateway (not drawn): save, re-save, create board, follow, and the engagement events the app batches. A re-save copies the image id from the pin being saved; a save with a new URL or new bytes asks the image service for the canonical image first. Runs the cheap save-time spam checks (account age and velocity, rate limits, link domain reputation) and relays pin events to the bus through an outbox.
• Image service (canonical images · pipeline): Owns the canonical image registry and the media pipeline. Synchronously: normalised source URL, then SHA-256 of the decoded pixels, to an existing image id or a new one. Asynchronously: the three widths, width, height and dominant colour, a 64-bit perceptual hash, object detection, embeddings for the image and each object, and a near-duplicate check that folds resized copies into the canonical image under an alias. One record per distinct image, ~5 B of them.
• Object storage (S3 class · ~3 PB): Originals and the three widths, keyed by canonical image id and width: ~600 KB per image, ~3 PB in total, growing ~1.2 TB a day. Written once and never modified, which is what lets the CDN cache forever. Old originals move to a colder tier; the sizes can always be regenerated from them.
• Pin store (sharded MySQL · key=user_id): Pins (image id, board, link, description, and the image’s width, height and colour copied in at save time), boards and follows, sharded by owner so a board page or a profile is one shard. A pin row is ~300 B, ~30 TB for 100 B pins. A unique key on (board, image) makes a repeated save a no-op.
• Event bus (Kafka · key=image_id): pin.saved, pin.removed and image.removed, plus the app’s engagement events. Graph servers, the search indexer and the offline builds each consume it at their own pace, so a slow consumer never slows a save. Pin events are keyed by image id, so every save of one image is processed in order by one consumer.
• Home feed service (candidates · rank · blend): Builds the home feed and “more like this”. On the first page of a session it gathers ~2,000 candidates from graph walks seeded by the user’s recent pins, followed boards and people, and embedding neighbours, has the ranker score them, then blends for diversity (one card per image, at most two per board, a cap per link domain) and caches ~200 ranked pins for 30 minutes. Later pages are reads of that list, and each request carries what the user engaged with, so the next refill uses it.
• Feed cache (Redis · TTL): Three short-lived key families: each session’s ranked list (~6 KB, 30 minutes, ~110 GB at peak), each board’s newest 50 pin ids for its followers (10 minutes), and each canonical image’s related-pin candidates (~500 ids, 6 hours). Everything in it can be recomputed, so a lost node costs latency, never data.
• Graph walk service (pin-board graph in RAM): Holds the whole pruned bipartite graph of canonical images and boards (~3 B nodes, ~20 B edges, ~185 GB) in RAM on every server, as compressed adjacency arrays in both directions, and answers random-walk queries in ~10 ms of CPU, the approach of Pinterest’s published Pixie system. Sharding would put most steps of a walk on the network, so it scales by replicas. A daily snapshot plus an in-memory overlay of today’s saves from the bus makes a new save walkable within seconds.
• Model serving (embedding ANN · GPU ranker): Two things the feed calls. A nearest-neighbour index of graph-aware image embeddings, in the spirit of Pinterest’s PinSage paper (each image embedded from its own visual and text features and its graph neighbourhood): ~2 B recommendable images compressed to ~144 GB across 6 shards. And a GPU ranker that predicts save, close-up, click-through and hide for ~1,000 candidates, on engagement aggregated across every save of an image. Both are loaded daily from the offline builds.
• Search service (text tiers · query encoders): Text and visual search, ~7 k and ~400 queries a second at peak. Holds the inverted index, one document per canonical image built from every save’s description and board name plus the link’s page title, as a daily main tier and a real-time tier fed from the bus. Embeds text queries and image crops into one shared image space, queries the visual index, fuses lexical and vector candidates, filters removals and ranks.
• Visual index (IVF-PQ · ~10 B vectors): Embeddings of ~5 B whole images and ~5 B detected objects in one image space, which a text encoder is also trained into: 10 TB as float32, ~720 GB as 64-byte PQ codes, held in RAM in 24 shards by image id with full vectors on NVMe for re-ranking. Rebuilt weekly with fresh centroids and codebooks; an HNSW fresh tier holds the last 7 days in full precision, and every query reads both.
• Offline builds (daily · weekly · versioned): Daily: snapshots the pin store into the pin-board graph, prunes it and ships it to the graph servers; recomputes image embeddings and the ranker; aggregates engagement onto canonical images; rebuilds the main text tier; scores spam and quality per image, board, account and link domain. Weekly: rebuilds the visual index. Every artefact is versioned, loaded beside the old one and checked before it replaces it.

User flows

1. Save an image from the web. The core write. Most of the work is deciding whether we already hold this image, because 90 % of the time we do, and a save must cost a row, not a copy.
   1. The user saves an image from a recipe site to their “Weeknight dinners” board. The browser button sends the image URL, the page URL and the alt text, not the bytes; an upload from a phone would first go straight to object storage with a presigned URL, as in Design Instagram. The client generates an idempotency key, so a retried save does not create a second pin.
   2. The pin service asks the image service for the canonical image behind that URL. First a lookup of the normalised URL (lowercased host, tracking parameters stripped): a popular image is saved from the same address thousands of times, so most web saves end here with no download. On a miss the service fetches the file and looks up a SHA-256 of its decoded pixels, which catches the same picture served from another address or with different metadata.
   3. For an image never seen before, it stores the original and writes the three fixed widths. Widths 236, 474 and 736 px in WebP, with JPEG copies for old clients, keyed by image id and width: ~600 KB with the original. Width, height and the dominant colour (a small k-means over a 32 px thumbnail that ignores near-white backgrounds) are computed here, because the grid needs them before any image byte is downloaded.
   4. The pin row is written with the image’s size and colour copied in, and the save returns. Copying width, height and colour into the pin makes hydration one read per pin, and it is safe because a canonical image never changes. The row and its outbox event commit in one transaction on the owner’s shard; a unique key on (board_id, image_id) turns saving the same image to the same board twice into a no-op.
   5. In the background the image service detects objects, embeds the image and each object, and adds them to the visual index’s fresh tier. A detector proposes boxes with categories (lamp, sofa, shoe); each box and the whole image get a 256-dimension vector from the same visual model. Boxes are stored on the image record, so a close-up shows tappable dots without running the detector again. The fresh tier is HNSW in full precision, so the vectors are searchable seconds after the insert.
   6. A near-duplicate check on the new vectors folds the image into an existing canonical one if it is the same picture. The nearest vectors are only candidates; the 64-bit perceptual hashes must differ in 6 bits or fewer and the aspect ratios agree within 1 %. That means the same picture at another size or quality; a crop, a watermark or overlaid text stays a separate image linked as similar. The existing canonical image always wins, so its URLs and sizes never change; the new id is kept as an alias so nothing that already saw it breaks, and the duplicate’s bytes are deleted after 30 days.
   7. The pin event reaches the graph servers, which add the edge to today’s overlay, and the search indexer. Every graph server appends (image, board) to an in-memory overlay that walks read alongside the daily snapshot: 20 M edges a day in both directions is ~320 MB. The search service adds the pin’s words to the image’s document in its real-time tier within about 10 seconds. The save returned long before either.
2. Open the home feed. The main read. Candidates come mostly from the graph, not from follows; they are ranked and blended once per session and served in pages from a cache. Every card carries enough metadata to lay out the masonry grid before a single image loads.
   1. The app asks for the first page of the home feed. The gateway (not drawn) authenticates and forwards. There is no session list for this user in the cache, so this request runs the funnel; the next pages will not.
   2. The feed service picks query pins from the user’s recent activity and asks the graph for random walks from them. Up to 20 query pins: recent saves weigh more than close-ups, which weigh more than clicks, decaying over weeks. Walks step image → board → image, jump back to a query pin now and then, and count visits; images reached from several query pins are boosted, and the walk stops early once enough images have high counts. ~1,000 images in ~20 ms.
   3. In parallel it gathers recent pins from followed boards and people, and embedding neighbours. The follow list (capped at the ~200 most engaged boards) comes from the pin store; each board’s newest 50 pin ids come from the cache, read through with a 10-minute TTL, so a board with a million followers costs one store read every 10 minutes. The user’s recent pins are clustered into up to 5 interests, and each cluster centre queries the embedding index for 200 neighbours, which catches images the graph has not connected yet.
   4. Candidates are merged by canonical image and filtered, and the ranker scores about 1,000. One image saved by three followed people is one candidate with three source tags, which is itself a strong feature. Filters drop images the user saved or hid, removed images (a bitmap of 5 B bits, 625 MB, on every feed host) and low quality scores. A light model trims ~2,000 to ~1,000, and the GPU ranker predicts save, close-up, click-through and hide from engagement summed over every save of each image.
   5. The blender orders them for diversity and caches about 200 ranked pins for the session. Greedy picks from the top: no two near-identical images on one screen, at most 2 per board and 3 per link domain in any 25, a spread of topics, and followed pins kept between 15 and 30 %. Each image is shown as the followed person’s save if there is one, otherwise as its representative pin (the save with the best description and a working link, chosen offline).
   6. The first 25 are hydrated in one batched read and returned with width, height and colour. Pin rows already carry the image’s dimensions and colour, so hydration is one multi-get grouped by shard, ~10 ms. The app puts each card in the currently shortest column, sizes it from the aspect ratio and paints its colour at once: the grid is fully laid out before any image arrives, and nothing jumps when they do.
   7. The app loads each tile from the CDN at the width its column needs. A two-column phone asks for 474 px, desktop for 236 or 474 px. URLs never change, so the head of popular images is nearly always an edge hit; a miss goes to a regional shield and then to object storage. Tiles below the fold load as they approach the viewport.
   8. Scrolling reads the next 25 from the cached list, and engagement rides along on the request. Page 2 is a cache read, a skip of anything hidden since, and a hydrate: ~20 ms. The request carries the pins the user saved or opened on earlier pages, and when ~50 entries remain the feed service refills the list in the background with those pins as fresh query pins, so the feed follows the session.
3. A pin goes viral: more like this. The scale-breaking case. One image is saved 100,000 times in a day and opened millions of times. Because a pin is a save of a canonical image, it stays one record, one URL and one cache entry; the risk moves into the graph, where the image becomes a hub.
   1. Thousands of people save the same image; each save is a new pin row and one more edge on the same canonical image. Re-saves carry the source pin, so the image service is not called and no bytes move. 100,000 saves a day is about one a second for this image, landing on 100,000 different owners’ shards: nothing is hot. A copy per save would have been 60 GB of duplicate bytes for this one picture.
   2. Millions open it; every close-up is the same CDN URL at 736 px. All 100,000 pins share one image id, so they share one URL per width and one cache entry per PoP. The first request at each PoP misses to the shield, and the shield coalesces concurrent misses, so object storage sees one read per region however many arrive at once.
   3. The close-up asks for more like this, and the image’s related-pins candidates are a cache read. Related pins depend on the image, not the viewer, so the unpersonalised candidates (~500 ids) are cached per canonical image for 6 hours: one walk serves millions of opens. The feed service only re-ranks the top 200 with the viewer’s features and drops what they have already saved.
   4. On a miss, the feed service walks from this one image and adds embedding neighbours. A walk from a single query pin is the related-pins shape: image → the boards it was saved to → the other images on those boards. Embedding neighbours add look-alikes and conceptual matches that share no boards. Only one miss per image per 6 hours reaches the graph, which keeps related-pin walks to ~7 k a second at peak.
   5. Inside the graph the viral image is a hub, so its degree is capped and its visits are discounted. With 100,000 boards, walks from unrelated starting points would keep landing on it, and it would appear in everyone’s results. The daily build keeps at most 10,000 of a hub’s board edges (the boards whose topics best match the image), the overlay caps new edges per node per day, and scoring divides visits by a power of the image’s degree. Popularity still helps; it cannot crowd out relevance.
   6. Engagement on all 100,000 pins is summed onto the canonical image for ranking. The ranker reads one save rate and one close-up rate for the image, not 100,000 thin ones, which is why a pin saved by someone with three followers still ranks on the image’s whole history. Aggregation runs hourly: pins are evergreen and their value is measured over weeks, so per-second counters would buy nothing here.
4. Visual search, with a slow shard. Search over ~10 B vectors that only fit in RAM once quantised. The query fans out to 24 shards and one of them is slow; the design still returns a good answer on time.
   1. The user taps the lamp in a living-room pin, or draws a box around it. For a pin, the detector’s boxes were stored at save time, so the app shows tappable dots as soon as the close-up opens. Tapping a stored box sends its id; a drawn box or a camera photo sends the crop.
   2. The search service embeds the crop into the shared image space. A stored box already has its vector from save time, so that case skips the model entirely. A new crop runs the visual encoder on a GPU in ~15 ms; a camera photo first runs the detector (~30 ms) and searches with the most central object. It must be the same model version as the index, or the distances mean nothing.
   3. It queries all 24 shards of the main tier and the fresh tier in parallel. Each shard holds ~420 M PQ codes in an IVF of 65,536 lists; the query scans the 64 nearest lists (~400 k codes, ~5 ms with SIMD lookup tables) and re-scores its best 200 against full vectors read from local NVMe. The fresh tier, HNSW over the last 7 days in full precision, returns its own top 200.
   4. One shard is slow: after its p95 the request is hedged to a replica, and at the deadline the merge goes ahead without it. Shards are by image id, so each holds a random 1/24 of the corpus: answering from 23 shards loses about 4 % of candidates spread evenly, not a whole category. That is the reason the index is not partitioned by category, even though a lamp query only wants lamps. The response is marked partial and the shard’s latency is alarmed on.
   5. Hits are merged, grouped by canonical image and filtered. Several objects of one image, or an image found in both tiers, collapse to one result with the best distance. Removed and spam images are dropped against the removal bitmap. A hit whose detected category disagrees with the query box’s (a lampshade print on a dress) is demoted rather than dropped.
   6. The top results are ranked on similarity, quality and engagement and returned with layout metadata. Visual distance leads; image quality, the canonical image’s save rate and a working, non-spam link domain break near-ties, which matters most for products. Results carry width, height and colour like every other grid, and show each image as its representative pin.
5. A new pin is found; a spam pin vanishes. The background path. The big indexes are rebuilt daily or weekly, so freshness comes from small real-time tiers merged at query time, and removal comes from a filter applied after the merge rather than from editing the big indexes.
   1. At 10:00 someone saves a brand-new photo of a brass floor lamp, described as “my reading corner”. The save path of the first flow: a new canonical image, its sizes, a pin row. Nothing in the daily text tier, the weekly visual build, the daily graph or the daily embeddings knows about it yet.
   2. Within seconds it is in the real-time text tier and the visual fresh tier. The real-time text tier is a small in-memory index of the documents changed since the last daily build, refreshed every ~10 s. The visual fresh tier already has the image’s vectors from the pipeline. Both are tiny next to their main tiers, hours or days of data against billions, so they rebuild their own structures cheaply.
   3. At 10:04 a user searches “brass floor lamp”; the text index and the query embedding run side by side. Lexical: both text tiers return images whose aggregated words match; each document is built from every save’s description and board name, so a popular image is easy to find under words its first saver never used. Semantic: the text encoder maps the query into the image space, and both visual tiers return images that look like a brass floor lamp. The new pin matches no word of the query and is found by its picture.
   4. Overnight the builds fold the day into the main tiers and trim the real-time ones. The daily build snapshots the pin store into a new pruned graph and new embeddings and rebuilds the main text tier; the weekly one rebuilds the visual index with fresh centroids and codebooks. Each version is loaded beside the old one, checked (recall against exact search on sampled queries, node and degree counts) and switched by one pointer, and then the real-time tiers drop what the main tiers now cover.
   5. Meanwhile a burst of day-old accounts saves one image 3,000 times, each with a link to a different new domain. Deduplication is what makes this visible: one canonical image, thousands of saves, thousands of unrelated domains registered last week, from accounts a day old. Save-time checks already slowed these accounts (velocity limits, domain age); the hourly spam model scores the image, its boards, the domains and the accounts together, and the cluster crosses the removal threshold.
   6. The removal is applied once, to the canonical image, and reaches every surface as an event. The image and its pins are marked removed and image.removed is published. Graph servers tombstone the node so walks step over it, and the search service and feed hosts set its bit in their removal bitmaps, which also filter cached session and related lists at read time. Nothing in the main indexes is edited; the next builds simply leave it out.

Deep dives

The theory behind it

• Recommendation systems: How large recommendation systems are built: candidate generation, ranking and re-ranking, embeddings and two-tower models, features and feature stores, offline and online serving, feedback loops, cold start, and how to evaluate them.
• Approximate nearest neighbour indexes (HNSW, IVF, PQ): How vector databases find similar embeddings fast: why exact search does not scale, HNSW graphs, IVF clustering, product quantisation and other compression, the recall versus latency versus memory trade-off, filtering, updates and deletes, sharding, and choosing parameters.
• Storing and querying graphs: Social graphs and other graph data in system design: adjacency lists in a key-value store, graph databases, friends-of-friends and mutual friends, celebrity nodes, sharding a graph, and what Facebook's TAO does.

Related

• Design a Recommendation System
• Design a RAG System
• Design Google News
• Design a Vector Database
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit