Real architecture · Staff
Meta Threads: 100 million users in 5 days
Real production architecture. Key points: reuse of Instagram infrastructure and capacity estimation.
Short answer
Real production architecture. Key points: reuse of Instagram infrastructure and capacity estimation. Threads was launched by Meta on July 5, 2023, and passed one hundred million sign-ups in its first five days. The source for this case is Meta's own engineering write-up on the infrastructure behind that launch.
01 · CONTEXT
A launch announced with almost no notice
Threads was launched by Meta on July 5, 2023, and passed one hundred million sign-ups in its first five days. The source for this case is Meta's own engineering write-up on the infrastructure behind that launch.
A small team built the product in about five months of engineering work, and the infrastructure teams learned of the date with only two days' notice. According to the write-up, the infrastructure was not built specifically for Threads: it had been under construction for many of the company's products.
The write-up highlights two components: ZippyDB, a distributed key-value store, and Async, an asynchronous functions platform. The next sections cover each one.
Threads posts and replies live in TAO, backed by MySQL, which stores the social graph.
ZippyDB, the key-value counterpart to MySQL, stores counters, state, and feed and search ranking.
Async runs work that does not need to block the user.
02 · CAPACITY
ZippyDB: two levers for growing fast
ZippyDB runs on a common hardware pool. New machines added to the service are absorbed within a few hours.
But approving and reallocating capacity end to end could still take on the order of a couple of days. The team also relied on multitenancy, which lets keyspaces with complementary demands share the same hosts without one affecting the other's service level.
There was also slack in the pool. Shifting unused allocations between keyspaces and letting hosts run busier allows a keyspace to grow almost immediately and sustain it for a short interval.
| New hardware | Existing slack | |
|---|---|---|
| Base | Common hardware pool | Unused allocations between keyspaces |
| Velocidade | Absorbed within a few hours | Almost immediate growth |
| Limite | Capacity approval can take on the order of a couple of days | Sustainable for a short interval |
03 · RESHARDING
Increasing the number of shards without stopping clients
ZippyDB's resharding protocol increases a use case's sharding factor (the horizontal scale) without downtime for clients. The design uses two levels: clients hash keys to logical shards, which are mapped to a set of physical shards. It is an example of database sharding.
Clients hash keys to logical shards, mapped to the physical shards of the original mapping.
When the use case grows, a new set of physical shards is provisioned.
The new logical-to-physical mapping is installed on clients through a live configuration change, with no downtime.
Resharding uses a coordinator-worker model, and the executors atomically move each logical shard from the original mapping to the new one.
Once all logical shards are migrated, the resharding finishes and the original mapping is removed.
The coordinator-worker model was designed to scale horizontally and to allow resharding to be sped up when needed, as in the Threads launch. New use cases usually start small and go through resharding as growth demands; here, the team saw it needed to prepare Threads for a hundredfold growth by resharding proactively.
The resharding finished in time for the traffic opening, at midnight UK time.
04 · ASYNC WORK
Async: following millions of people without blocking sign-up
Async is Meta's serverless functions platform and can defer computation to lower-usage hours. Typical jobs are those that do not require blocking an active user and can run anywhere from a few seconds to several hours after the action.
On Threads, Async let new users follow the people they already followed on Instagram. Running this follow through Async avoids blocking the user's sign-up.
The new user asks to follow on Threads the people they already follow on Instagram.
The request becomes queued work in Async, which avoids blocking the user's sign-up.
When celebrities joined, millions of people could end up in the queue to follow them.
Execution is managed within rate limits so as not to overload downstream services.
Async adjusts the flow to its own capacity and to that of dependencies such as the graph database, with no manual intervention.
The job volume exceeded the initial expectation by several orders of magnitude. Even so, Async absorbed it, queueing it for controlled execution, and the corresponding notifications also went through it.
05 · LESSONS
What scaled on its own and where there was effort
The source points to shared infrastructure that stood the test of time and a high degree of automation. Apart from the effort to secure capacity on short notice, redistribution, balancing, and scaling of workloads happened automatically and transparently.
| How it worked | Point of attention | |
|---|---|---|
| Overall capacity | Redistribution, balancing, and workload scaling | Securing capacity on short notice |
| Job queue (Async) | Flow adjusted to capacity, with no manual intervention | Volume far above the initial expectation |
| ZippyDB | Shard mapping swap without downtime | Prepare Threads for much larger growth with proactive resharding |
Frequently asked questions
What is Meta Threads: 100 million users in 5 days?
Real production architecture. Key points: reuse of Instagram infrastructure and capacity estimation.
What does the Meta Threads: 100 million users in 5 days design cover?
It is organized in these sections: A launch announced with almost no notice, ZippyDB: two levers for growing fast, Increasing the number of shards without stopping clients, Async: following millions of people without blocking sign-up, and What scaled on its own and where there was effort.
How long is Meta Threads: 100 million users in 5 days and what level is it?
It takes about 18 minutes to read and is rated Staff level.
Now design it yourself
Run this case as an interview in the System Design school: you make the decisions, the tutor challenges them and you see how your design scores.