Scaling Infrastructure in Five Days

When Meta launched Threads on July 5, 2023, the app crossed 100 million sign-ups within its first five days. That success came from a small engineering team that had spent just five months on technical work—and from infrastructure teams that received only two days’ notice before the production launch was confirmed. The decision to proceed was based on the maturity of Meta's existing infrastructure, built and refined over more than a decade for other products at scale.

None of this infrastructure was purpose-built for Threads. It was already in place, designed for scale, growth, performance, and reliability across Meta’s product family. As Threads grew at a pace no one predicted, the underlying systems absorbed the surge. Two components played particularly important roles: ZippyDB, the distributed key/value datastore, and Async, the asynchronous serverless function platform.

ZippyDB’s Keyspace Scaling

ZippyDB is a distributed key/value database run as a fully managed service at Meta. It is built on Meta’s common infrastructure, so keyspaces can be scaled up or down relatively easily and placed flexibly across data centers. While Meta uses TAO backed by MySQL for social graph storage—where Threads posts and replies live—ZippyDB serves as the key/value counterpart, handling counters, feed ranking and state, and search.

Two key features enable fast keyspace scaling. First, ZippyDB runs on a common pool of hardware integrated with Meta’s capacity management framework. When new capacity is allocated, machines are automatically added to the service’s pool, and a load balancer moves data onto them. Thousands of new machines can be absorbed within a few hours. Still, the end-to-end process of approving capacity, potentially draining it from other services, and adding it to ZippyDB can take a couple of days—so the service also needs to handle surges on shorter notice.

That immediate absorption relies on multi-tenancy and strong isolation features within the service architecture. Different keyspaces with complementary load demands can share underlying hosts without impacting each other’s service levels when workloads run hot. Slack exists in the host pool from unused capacity of individual keyspaces and buffers reserved for disaster recovery. Operators can shift unused allocations between keyspaces through config changes—letting hosts run at higher utilization so a keyspace can ramp up almost immediately and sustain that level for a few days. These are routine operations, supported by automation built around the tools.

Combining strong multi-tenancy with the ability to absorb new hardware allows the service to scale nearly seamlessly, even under sudden, large new demand.

Preparing ZippyDB for 100x Growth

ZippyDB’s resharding protocol can quickly and transparently increase the sharding factor—the horizontal scaling factor—of a use case with zero downtime for clients, while maintaining full consistency and correctness guarantees. This supports rapidly scaling out use cases on the critical path of new product launches, even when load increases by 100x.

The mechanism works by having clients hash keys to logical shards, which map to a set of physical shards. When a use case grows and needs resharding, a new set of physical shards is provisioned, and a new logical-to-physical shard mapping is installed in clients through live configuration changes—no downtime required. Hidden access keys on the server and smart data migration logic in resharding workers allow atomic movement of a logical shard from the original mapping to the new one. Once all logical shards are migrated, resharding is complete, and the original mapping is removed.

Since scaling up use cases is a critical operation for new product launches, Meta invested heavily in this stack to ensure ZippyDB scaling doesn’t block product launches. The resharding stack follows a coordinator-worker model, making it horizontally scalable so resharding speeds can be increased when needed—as they were during the Threads launch. Emergency operator tools also help handle sudden use case growth.

For Threads, the approach was to start small and reshard as growth required, preventing overprovisioning and promoting capacity efficiency. As viral growth became evident, the team proactively resharded in preparation for 100x growth. With automation tools developed previously, resharding completed just in time—as the Threads team opened traffic at midnight UK time—enabling a smooth user experience as the user base soared.

Async’s Scalable Workload Execution

Async (also known as XFaaS) is a serverless function platform that can defer computing to off-peak hours. It processes trillions of function calls per day on more than 100,000 servers and supports multiple programming languages, including HackLang, Python, Haskell, and Erlang.

The platform abstracts deployment, queueing, scheduling, scaling, and disaster recovery, letting developers focus on core business logic. Code uploaded to Async automatically inherits hyperscale attributes, along with configurable retries, time for delivery, rate limits, and capacity accountability.

Async workloads are typically those that don’t need to block a user's active experience and can run anywhere from seconds to hours after a user action. For Threads, Async was critical in letting new users quickly build community by following people they already followed on Instagram. When a new user chooses to follow the same set of people on Threads, the computationally expensive operation of executing that request is handled via Async—avoiding any blocking or negative impact on the onboarding experience.

Processing this for 100 million users in five days required significant computing power. When celebrities joined, millions of people could be queued to follow them; both the follow operation and corresponding notifications also ran in Async, enabling scalable operations under heavy load.

The volume of Async jobs from rapid Threads onboarding was several orders of magnitude higher than initial expectations, yet Async absorbed the load and queued it for controlled execution. Rate limits ensured notifications and connections were sent in a timely manner without overloading downstream services. Async automatically adjusted execution flow to match its own capacity and that of dependent services, such as the social graph database—without manual intervention from Threads or infrastructure engineers.

Infrastructure and Engineering Culture

Threads’ development in just five months highlights the strengths of Meta’s shared infrastructure, which has withstood the test of time and lets product teams move fast while scaling successful products. High automation levels meant that—except for securing capacity on short notice—automatic redistribution, load balancing, and workload scaling happened smoothly and transparently.

Meta’s move-fast engineering culture also played a role, with engineers taking strong ownership and collaborating across teams. The SEV incident-management culture helped bring visibility, focus, and action where coordination was needed quickly. Together, these factors ensured the success of the Threads launch.