A look at how Meta serverless works. Meta’s serverless platform runs internal webhooks and async jobs for Facebook, Instagram, and WhatsApp at a scale that dwarfs every public serverless offering combined. The architectural choice that makes it work is TwSF (Meta’s internal async workflow framework), purpose-built for the call patterns Lambda was never designed for.
How Meta Serverless Works: The problem at scale
Meta’s internal workload looks nothing like the typical Lambda use case. Instead of HTTP-triggered functions serving user requests (Lambda’s bread and butter), Meta’s serverless handles async internal webhooks: an event happens somewhere in the Facebook/Instagram/WhatsApp stack (a post is created, a message is sent, an ad campaign launches), and dozens of internal services need to be notified and run their own logic. Each of these downstream services may need to scale independently, may have very different latency requirements, and may be owned by completely different teams. Running them all as long-lived services would waste enormous resources; running them on AWS Lambda would mean paying Lambda’s margin on billions of internal invocations per day.
The core architecture
A webhook caller (any internal Meta service) hits the Frontend + Balancer, which authenticates and routes to the Worker Scheduler, the TwSF (Meta’s internal async workflow framework) layer. TwSF is purpose-built for fanout: a single inbound event can trigger hundreds of downstream worker invocations, each scheduled with its own retry policy, priority, and quota. The scheduler dispatches to the Worker Pool, warm containers running internal-language handlers (Hack, Python, C++). Workers can access Meta’s internal services (TAO graph store, memcache, internal ML models) but only via Bin ACL, capability-scoped access control that limits each worker to its approved internal APIs.
TwSF is the architectural choice
AWS Lambda is request-response: each invocation is independent, stateless, and short-lived. Meta’s internal workloads are mostly workflows: multi-step async processes with branching, retries, and long waits between steps (e.g., “wait until this user’s friend graph updates, then process this notification”). TwSF handles workflow semantics natively: durably persisted state per workflow, automatic retries on failure, and dependency-aware scheduling. Lambda could do all of this with Step Functions, but Step Functions adds latency and cost; TwSF is a single integrated system.
The published engineering blog compares the cost model: TwSF at Meta’s scale is dramatically cheaper per invocation than AWS Lambda, both because there’s no profit margin and because the workflow semantics reduce redundant cold starts. Meta could not run its current async workload on AWS Lambda without spending billions more per year.
Bin ACL is the trust boundary
Internal services at Meta have different trust levels. A worker handling payment webhooks needs access to billing; a worker processing photo uploads needs access to media storage; the two should never share credentials. Bin ACL is the capability system: each worker is tagged with its permitted internal API surface, and the frontend enforces the policy. A worker that tries to call an internal service outside its bin is rejected at the network layer. This is more granular than AWS IAM roles: Meta’s internal API surface is enormous, and fine-grained ACLs are how they keep blast radius small when a worker is compromised.
The one non-obvious insight
Meta’s serverless platform is internal-only. Unlike Lambda, it’s not a product. It’s infrastructure. The trade-off is significant: Lambda has to support arbitrary external customers with arbitrary code; Meta’s platform only supports Meta’s own teams writing Meta-approved code against Meta’s internal APIs. That narrower scope is what lets TwSF, Bin ACL, and the workflow semantics work: every user is in the same trust boundary. The lesson for external serverless platforms: narrower scope enables richer abstractions. The richest serverless features (durable workflows, capability-scoped access, native ML integration) are only available inside companies that run their own.
Meta’s serverless platform is internal-only, runs at a scale AWS Lambda can’t match, and uses purpose-built abstractions (TwSF for workflows, Bin ACL for trust) that public serverless can’t offer. The narrower scope is the enabler: external serverless is fundamentally more constrained.