Guides

Facebook Architecture Explained: How Facebook Works Behind the Scenes

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

Short answer: Facebook runs in Meta's own data centres: more than 20 data centre regions with millions of machines, managed by Meta's container system Twine (2024). The web code is written mostly in Hack, running on HHVM. Thousands of microservices sit behind it. Your friends, posts, likes and comments are a giant social graph, stored in MySQL (with the MyRocks storage engine) and served through a huge cache layer called TAO, plus Memcache. Facebook does not use AWS, Google Cloud or Azure for its main app.

Suppose you open Facebook and see a friend's photo

You open Facebook in Nagpur. Your feed shows your cousin's wedding photo, 120 likes and comments from relatives. In simple terms:

1. Your request reaches the nearest entry point of Meta's network and its load balancers (Meta open-sourced its Katran load balancer in 2018).
2. A web server running Hack on HHVM starts building your feed.
3. It calls many microservices, for example ranking, ads and notifications, which run as containers on Twine.
4. Graph data such as who your friends are, who liked the photo and the comments comes from TAO, a cache that sits in front of MySQL.
5. Other hot data comes from Memcache.
6. The photo file comes from Meta's BLOB storage and edge caches close to you.
7. Your phone shows the post with likes and comments.

What architecture style does Facebook use?

Facebook's architecture is a mix of one huge web application and thousands of services, all on Meta's private infrastructure.

1. Today: thousands of microservices on Twine. In 2024, thousands of microservices power Facebook, Instagram and WhatsApp, deployed as Twine jobs across 20+ data centre regions.
2. Graph-first data model: everything is an object (user, post, photo) or an association (friend of, liked, commented). TAO stores these.
3. Read-heavy design: people read far more than they write, so huge cache layers (TAO, Memcache) protect the databases.
4. Replicated MySQL with Raft (2023): Meta moved its MySQL replication to a Raft-based system to make failover safer and faster.
5. Key-value at scale: ZippyDB is Meta's distributed key-value store; in 2026 Meta added ZGateway, a proxy in front of ZippyDB.

Facebook architecture diagram (public parts)

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

What does Facebook use? Main technologies

Which cloud provider does Facebook use?

Facebook uses no public cloud for its main app. It runs on Meta-owned data centres.

1. As of 2024: 20+ data centre regions and millions of machines.
2. Services run as containers managed by Twine.
3. The same shared infrastructure also runs Instagram, WhatsApp and Threads.

How it started: Facebook's data systems (2010 to 2019)

1. Haystack (2010): a photo store built to cut the disk reads needed per photo.
2. TAO (2013): a geographically distributed graph store; reads served by caches, data kept in sharded MySQL.
3. Scaling Memcache (2013): Facebook ran Memcache across regions, with leases to stop thundering herds and invalidations to keep caches fresh.
4. f4 (2014): "warm" BLOB storage for older photos, using erasure coding to save space.
5. Gorilla (2015): an in-memory time-series database for monitoring.
6. MyRocks (2017): Facebook moved its user database (UDB) from InnoDB to MyRocks (RocksDB inside MySQL), saving storage.
7. Katran (2018): open-source layer-4 load balancer.

How does Facebook store data?

1. MySQL (MyRocks engine) holds durable user and graph data; replication now uses Raft (2023).
2. TAO caches the social graph in every region.
3. ZippyDB stores key-value data for many services.
4. Haystack and f4 store photos and other BLOBs (hot and warm).
5. Exact current capacity numbers are not publicly shared.

How does Facebook monitor its systems?

1. Gorilla (2015): in-memory time-series database for metrics.
2. Scuba: fast in-memory data analysis used for debugging and monitoring.
3. For the 2026 World Cup, Meta prepared for record traffic spikes and reliability at scale.
4. Full current alerting setup is not publicly shared.

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

Suppose you want to build "GaavConnect", a small social network for your village and college friends. 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 both public subnets.
2. API and feed services on EKS in private app subnets.
3. Workers read SQS for notifications and feed fan-out.
4. Start with a few services; split more as the team grows.

3. Storage and databases

1. S3 + CloudFront for photos and videos.
2. Aurora for users and posts.
3. DynamoDB for likes and follow edges (a simple graph: partition key = user, sort key = friend).
4. ElastiCache in front, like Facebook's Memcache and TAO idea.

4. Monitoring

1. CloudWatch metrics and alarms on errors and latency.
2. X-Ray traces across services.
3. CloudWatch Logs Insights to search logs, a small cousin of Scuba.

Request flow diagram

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

Facebook versus our AWS design