A social product is launched on top of an existing platform's identity, graph and infrastructure, and reaches 100 million users in five days. Which components are safe to borrow, which must be isolated, and what does this say about coupling?

Why borrowing was the right call

Threads reached roughly 100 million sign-ups in five days by reusing Instagram's identity, social graph and infrastructure. Building a new user base, a new graph and a new serving stack would have made that impossible — the borrowed graph is the entire reason the growth curve existed, because sign-up was one tap on an account that already had followers.

This is coupling deliberately chosen for time-to-market and for a product property that could not otherwise exist. It is the correct decision, and it is still coupling.

Safe to borrow

• Identity and authentication. Read-mostly, already scaled far beyond the new load, and duplicating it would create an account-linking problem worse than the coupling.
• The social graph, read-only. Following relationships are read at very high volume and written rarely.
• Storage and infrastructure primitives — the distributed key-value tier, the graph cache, blob storage, the CDN. These are horizontally scalable platforms whose whole purpose is multi-tenancy.
• Deployment, observability and capacity tooling.

Must be isolated

• Write paths and hot data. New posts, new feed state, new counters. If the new product's write volume can saturate a shared write path, a launch failure becomes an outage of the established product, which is a catastrophically asymmetric risk.
• Ranking and feed generation compute, which is the expensive and least predictable part.
• Capacity pools, with an explicit priority. Borrowing capacity is fine; borrowing it without a defined eviction order means the established product loses to the experiment during contention.
• Anything with a different regulatory posture. Launch geography differed for exactly this reason.

The governing principle

Borrow the read-mostly, already-multi-tenant, horizontally-scalable substrate. Isolate anything where the new product's growth converts directly into load on the incumbent's critical path.

Reallocating capacity in real time

The mechanism that made this survivable is capacity borrowing with a priority order defined in advance — a global pool, products with tiers, and non-critical batch and offline work as the first thing displaced. The architectural requirement is that workloads are shaped so they can be shed: offline training, backfills, and recomputation jobs that can pause without a correctness problem.

The lesson is not "share everything." It is that sharing is safe exactly where load is decoupled from the incumbent's critical path, and dangerous everywhere else.