Design Pinterest

Problem statement

Design Pinterest: an image-centric discovery platform where users save (pin) images they find interesting, organize them into boards, follow other users, boards, and topics, and discover new content through an infinitely scrolling home feed, text search, visual search, and related-pin recommendations. The four contractual functional requirements are: pinning images to personal boards; visual search or object recognition; following boards or topics with recommended content; and an infinite scrolling feed tuned to each user's interests. The non-functional requirements are a CDN for fast image loading, horizontal scaling for millions of pins, caching for popular and trending boards, and machine learning for content recommendation.

The defining characteristic of this system is its read asymmetry. A pin is created once but potentially viewed, saved, and re-saved thousands of times over years; content is evergreen rather than ephemeral, unlike a microblog timeline where value decays in minutes. That single observation drives the entire architecture: aggressive multi-tier caching, a CDN that absorbs nearly all image bytes, precomputed ranked feeds, and asynchronous pipelines for everything expensive (rendition generation, embedding extraction, index building, fan-out). Writes are modest in rate but fan out explosively: one save can trigger follower feed updates, counter increments, event emission, and ML feature updates.

The second defining characteristic is that the graph is an interest graph, not a friendship graph. Edges connect users to boards, boards to pins, pins to pins (via co-save behavior), and users to topics. Recommendation therefore operates over a bipartite user-board-pin structure with billions of nodes; Pinterest's own PinSage paper (KDD 2018) describes learning embeddings on a web-scale graph of roughly 3 billion nodes and 18 billion edges, and its Pixie system runs biased random walks over a billion-node pin-board graph for related-pin retrieval. Those are real, published data points that anchor this design.

Public baseline versus design assumptions

Pinterest publicly reports more than 500 million monthly active users (company-reported ~522M MAU in 2024-2025 investor material) and hundreds of billions of saved pins (company statements cite 350B+ pins). Its early architecture is well documented: a Django monolith on MySQL that evolved into sharded MySQL, Memcached, Redis, Solr, and later a service-oriented architecture on AWS with Kafka, Hadoop, Spark, and Thrift services. For capacity planning this answer explicitly assumes 100M DAU, 4 sessions per DAU per day, 8 feed pages per session, and 25 pins per page, yielding 3.2B feed page impressions per day (~37K QPS average, ~110K QPS at a 3x peak). Unless a number is tied to a citation, it is a stated assumption, derived budget, or target.

The four architectural planes

1. Delivery plane: CDN edge, image renditions, client prefetch, infinite-scroll pagination.
2. Core service plane: pin, board, graph, feed, search, and notification services behind an API gateway.
3. Data plane: sharded MySQL for truth, Redis/Memcached for hot reads, object storage for images, vector index for visual search, warehouse for analytics.
4. Learning plane: Kafka event backbone, Spark/feature pipelines, embedding models (visual and graph), ranking models, and experimentation.

A strong interview answer keeps these planes separate: the feed must degrade to a cached or chronological fallback when the learning plane is down, and image delivery must survive core-service outages because the CDN serves renditions independently.