Guides

Snapchat Architecture Explained: Microservices Across AWS and Google Cloud

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 18 October 2026 · Last updated: 18 October 2026

Short answer: Snapchat is multicloud: its backend runs as microservices on Kubernetes across both AWS and Google Cloud. For years it ran as a monolith on Google App Engine; by 2020 the move to services cut compute costs by 65%. All service traffic goes through Envoy proxies in a service mesh managed by an internal tool called Switchboard. Machine learning runs on Snap's Bento platform, which handles over a billion predictions per second (2025).

Suppose you send a Snap to your friend

You take a funny photo at Marine Drive and send it to a friend. In simple terms:

1. Your app connects to Snap's edge, built on Envoy proxies.
2. The request goes to the right microservice, running in a Kubernetes cluster on AWS or Google Cloud.
3. Every service has an Envoy sidecar that adds TLS encryption and records metrics for each call.
4. Services call each other (for example friends, messaging, media) through the mesh.
5. Machine learning models on Bento rank Stories, friend suggestions and ads.
6. Your friend's app is notified and downloads the Snap.

What architecture style does Snapchat use?

Snap's architecture changed a lot in the last years.

1. Microservices with a service mesh (2020): each service has an Envoy sidecar; a central control plane sends routing and security settings to all Envoys.
2. Switchboard: Snap's hub where service owners configure their services, the same way on AWS and on Google Cloud.
3. Multicloud by design: Snap wanted to be able to move services between AWS, GCP and other providers, so it hides cloud differences where it can.
4. ML platform Bento (2025): hundreds of models trained per day, 500+ models in production, more than 1 billion predictions per second, an 800 TB online feature store and about 10 trillion events per day in feature pipelines.

Snapchat architecture diagram (public parts)

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

What does Snapchat use? Main technologies

Which cloud provider does Snapchat use?

Snapchat uses both AWS and Google Cloud. Since 2020 its microservices run in Kubernetes across both providers and that the design aims to make it possible to shift services between clouds.

What does the service mesh give Snap engineers?

Snap listed clear design rules for its new platform in 2020:

1. Secure by default: authentication, authorization and network security are built in, not optional.
2. Business logic separate from infrastructure: service code runs in a Docker container; Envoy handles the network.
3. Hide cloud differences: avoid deep provider dependencies so services can move between AWS and Google Cloud.
4. Same experience everywhere: central service discovery and management, wherever a service runs.
5. Easy new services: The goal: an intern should be able to set up a production-ready service by lunch time.

Snap picked Envoy because it supports gRPC and HTTP/2, client-side load balancing, circuit breaking, live config updates through its xDS APIs and detailed metrics, and because both AWS and Google Cloud invest in it.

How it started: a monolith on Google App Engine (until about 2018)

1. For years Snap's backend was one monolithic app on Google App Engine.
2. As Snap grew, engineers wanted to own their own services and data models and limit the blast radius of outages; Snap also wanted a path to AWS.
3. Over about two years (2018 to 2020) Snap moved to microservices on Kubernetes across AWS and Google Cloud, with Envoy as the common layer.

How does Snapchat store data?

1. Each microservice owns its own datastore, instead of one shared database (2020).
2. Bento has an 800 TB online feature store and petabyte-scale training data (2025).
3. The specific databases used for Snaps and chats are not publicly shared.

How does Snapchat monitor its systems?

1. Every Envoy sidecar publishes metrics on all inbound and outbound calls: latency, retries, errors, connections.
2. Further details of Snap's alerting stack are not publicly shared.

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

Suppose you want to build "ChitraChat", a photo-sharing chat app for friends. Here is a simple AWS-only 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 with a service mesh (for example Envoy-based).
3. Workers on SQS send notifications and delete expired snaps.

3. Storage and databases

1. S3 for media with lifecycle rules to delete old files; CloudFront to deliver.
2. DynamoDB inbox with TTL so snaps expire.
3. Aurora for users; ElastiCache for sessions.

4. Monitoring

1. CloudWatch and Envoy metrics.
2. X-Ray traces between services.

Request flow diagram

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

Snapchat versus our AWS design