Ravindra BagaleCourses & study guides Track your progress

Guides

Pinterest Architecture Explained: How Pinterest Serves Billions of Pins

Short answer: Pinterest runs on AWS. Its compute platform PinCompute is built on Amazon EKS (Kubernetes), including GPU clusters for AI serving (2026). Its in-house search system Manas moved onto PinCompute (2025). Data lives in MySQL and TiDB with a cache layer, and a new database ingestion framework uses Kafka, Flink, Spark and Iceberg (2026). Cloud resources are created through Terraform with a secure pipeline called RPP (2026).

Suppose you search Pinterest for Diwali rangoli ideas

You open Pinterest in Ahmedabad and search "Diwali rangoli". In simple terms:

  1. Your app calls Pinterest's services on AWS.
  2. Search runs on Manas, Pinterest's search system, now on the Kubernetes-based PinCompute platform.
  3. Recommendation models (for example for the home feed) retrieve and rank Pins for you.
  4. Pin and user data comes from MySQL, TiDB and cache infrastructure.
  5. Changes in these databases flow through Kafka and Flink into Iceberg tables for analytics.
  6. Images are shown in your feed; you save a Pin to your board.

What architecture style does Pinterest use?

Pinterest today has a central platform team providing shared compute and data systems.

  1. PinCompute on EKS: one internal platform for many workloads, from search to Gen AI serving on NVIDIA GPUs (2026).
  2. Search on Kubernetes (2025): while moving Manas to PinCompute, Pinterest found one in a million requests taking 100 times longer, caused by a cAdvisor memory metric scanning huge memory-mapped indexes; it disabled that metric on all nodes.
  3. Machine learning with Ray (2025): Pinterest scaled ML training and end-to-end pipelines with Ray.
  4. Secure infrastructure as code (2026): the Resource Provisioner Pipeline runs Terraform for AWS through central GitHub Actions with dual controls.

Pinterest architecture diagram (public parts)

This diagram shows only what Pinterest or its partners have shared publicly. Press Play to follow a request step by step.

Watch the orange dot follow each numbered step.
Pinterest architecture from public information (simplified)AWSData platformSimplified; based on publicly shared information.Pinnerapp or browserPinterest front endAPI layerServices on PinComputeAmazon EKS, GPUsManas searchon PinCompute (2025)MySQL + TiDBwith cache infraML: Ray, vLLMrecommendations, Gen AIRPPTerraform guardrailsKafka, Flink, Spark, IcebergDB ingestion (2026)
  1. You search for rangoli ideas.
  2. The front end receives the request.
  3. Services on PinCompute handle it.
  4. Manas finds matching Pins.
  5. Pin data comes from MySQL and TiDB.
  6. ML models rank results.
  7. Infrastructure changes go through RPP.
  8. Data changes flow into Iceberg for analytics.
  9. You save a Pin.
Diagram 1: the public parts of Pinterest's architecture. Simplified; based only on publicly shared information. Open the diagram as an image (PNG) · WebP

What does Pinterest use? Main technologies

LayerWhat Pinterest uses (public)What it does in simple words
CloudAWSHosts Pinterest
ComputePinCompute on Amazon EKSRuns services, search and AI
SearchManasIn-house search
DatabasesMySQL, TiDB, cache infrastructurePins, users, boards
Data ingestionKafka, Flink, Spark, Iceberg (2026)Database changes to the lake
MLRay, vLLM, NVIDIA DynamoTraining and serving
Infra as codeTerraform via RPP (2026)Safe AWS changes

Which cloud provider does Pinterest use?

Pinterest runs on AWS. In 2026 it runs PinCompute on Amazon EKS with NVIDIA GPUs and Terraform state stored in S3 in us-east-1 for its global AWS operations.

This 2025 move is a great real-world debugging story:

  1. Pinterest moved Manas, its search system, onto PinCompute, its Kubernetes platform on EKS.
  2. After the move, about one in a million search requests took around 100 times longer than normal, with spikes every few minutes.
  3. Manas keeps very large search indexes (over 100 GB) in memory-mapped files.
  4. The cause was cAdvisor, a container metrics agent. Its default working-set-size metric scanned and reset memory page flags every 30 seconds, which caused kernel lock contention on those huge indexes.
  5. The fix was to disable that cAdvisor metric on all PinCompute nodes.

The lesson for learners: when you move a heavy, memory-hungry system onto Kubernetes, even a default monitoring agent can change performance. Measure tail latency (p99.99), not just averages.

Data ingestion (2026)

Pinterest's next-generation database ingestion framework uses Kafka, Flink, Spark and Iceberg. In 2026 it added "partition finalization": markers that tell downstream jobs when a time partition of data is complete enough to read.

How it started: sharding MySQL

  1. Pinterest became famous for sharding MySQL: splitting Pins, boards and users across many MySQL databases with IDs that encode the shard.
  2. It used Kafka to throttle writes to MySQL shards in bulk write APIs.
  3. Pinterest has run Kafka at large scale for years.

How does Pinterest store data?

  1. MySQL and TiDB for online data, with cache infrastructure in front.
  2. Iceberg tables (fed by Kafka, Flink and Spark) for analytics.
  3. S3 for Terraform state and other storage.
  4. Image storage and CDN details are not publicly shared.

How does Pinterest monitor its systems?

  1. Pinterest's 2026 Metrics Board is an agent-ready metrics layer.
  2. cAdvisor runs on PinCompute nodes for container metrics.
  3. The full alerting stack is not publicly shared.

If we built an app like Pinterest on AWS (illustrative)

Please read this first

This section is a learning design by Ravindra Bagale. It is not Pinterest's real setup. Pinterest really runs on AWS. We use AWS here because it is what you learn in the AWS course.

Suppose you want to build "KalaBoard", a site for saving craft and art ideas. Here is a simple AWS layout.

1. Network: VPC, subnets, route tables, gateways

  1. Create one VPC with CIDR 10.0.0.0/16 in the Mumbai region (ap-south-1).
  2. Use two Availability Zones (A and B), so one AZ failing does not stop the app.
  3. In each AZ make three subnets: public (load balancer, NAT gateway), private app (your code) and private data (databases, cache).
  4. Attach one internet gateway (IGW) to the VPC. Public route table: 0.0.0.0/0 → IGW. This route is what makes a subnet public.
  5. Private app route table: 0.0.0.0/0 → NAT gateway, so servers can download updates but nobody can connect in from the internet.
  6. Private data route table: only the local VPC route. Use VPC endpoints to reach S3, DynamoDB and SQS without going over the internet.

2. Compute: where the code runs

  1. ALB in public subnets.
  2. Services on EKS, like PinCompute.
  3. Image resize jobs from SQS.

3. Storage and databases

  1. S3 + CloudFront for images.
  2. Aurora MySQL for users and boards.
  3. DynamoDB for pins and saves; ElastiCache for feeds; OpenSearch for search.

4. Monitoring

  1. CloudWatch and Container Insights.
  2. X-Ray traces.

Request flow diagram

Press Play. The numbered list below the diagram lights up with each step.

Watch the orange dot follow each numbered step.
If we built a Pinterest-like app on AWS (illustrative)AWS Region (for example ap-south-1, Mumbai)VPC 10.0.0.0/16Availability Zone AAvailability Zone BPublic subnet 10.0.1.0/24RT: 0.0.0.0/0 → IGWPublic subnet 10.0.2.0/24RT: 0.0.0.0/0 → IGWApp subnet 10.0.11.0/24RT: 0.0.0.0/0 → NATApp subnet 10.0.12.0/24RT: 0.0.0.0/0 → NATData subnet 10.0.21.0/24RT: local onlyData subnet 10.0.22.0/24RT: local onlyvia VPC endpointsIllustrative learning design only. This is NOT the company's real setup.Userphone appRoute 53DNS lookupCloudFrontCDN edge cacheAmazon S3pin imagesIGWApplication Load Balancerspans both AZsNAT gatewayNAT gatewayPin APIEKS pods (auto scaling)Pin APIEKS pods (auto scaling)ElastiCachehome feed, boardsAurorausers, boardsElastiCachehome feed, boardsAuroraread replicaSQSimage processingDynamoDBpins, savesCloudWatch + X-Raymetrics, logs, traces
  1. You open KalaBoard. Route 53 answers.
  2. Images via CloudFront.
  3. From S3.
  4. API calls through the internet gateway.
  5. The ALB forwards to a pod.
  6. The pin API builds your feed.
  7. Feed from ElastiCache.
  8. Boards in Aurora; saves in DynamoDB.
  9. New image job to SQS.
  10. CloudWatch watches.
  11. You save a Pin.
Diagram 2: an illustrative AWS design for learning. Pinterest does not necessarily run like this; see the sections above for what is publicly known. Open the diagram as an image (PNG) · WebP

Pinterest versus our AWS design

PartPinterest (public info)Our AWS design
CloudAWSAWS
ComputePinCompute on EKSEKS
DatabasesMySQL, TiDBAurora MySQL, DynamoDB
SearchManasOpenSearch
DataKafka, Flink, Spark, IcebergKinesis, Glue, Iceberg on S3
MonitoringNot fully publicCloudWatch

Quick quiz: check what you learned

  1. Which cloud does Pinterest use?

    1. AWS
    2. Only own servers
    3. Azure only
    4. Oracle Cloud
    Show answer

    A. Pinterest runs on AWS.

  2. What is PinCompute built on?

    1. Mesos
    2. Amazon EKS
    3. Windows
    4. Hadoop
    Show answer

    B. PinCompute uses AWS EKS.

  3. What is Manas?

    1. A photo filter
    2. A login service
    3. Pinterest's search system
    4. A CDN
    Show answer

    C. Manas is Pinterest's search.

  4. Which databases does Pinterest mention in 2026?

    1. Oracle only
    2. Access
    3. FoxPro
    4. MySQL and TiDB
    Show answer

    D. In 2026 Pinterest uses MySQL and TiDB.