A super-app combines messaging, payments, social feeds, mini-programs and notifications in one product used by hundreds of millions daily. What is the dominant reliability risk, and what structural property addresses it?

The dominant risk

Correlated failure across capabilities that users perceive as one product but which have completely different reliability requirements.

A super-app's messaging must never stop. Payments must never be wrong. A social feed may be stale. A mini-program may be unavailable. Those are four different reliability contracts, and if they share infrastructure, they share failures — so the feed's bad day becomes the payment system's bad day.

The failure mode is not any single component breaking. It is that a component with a weak requirement is allowed to consume a resource that a component with a strong requirement depends on.

The structural property

Isolation proportional to the reliability contract, enforced at the resource level rather than by convention:

• Separate failure domains per capability. Messaging, payments and feed do not share databases, connection pools, caches or compute. Sharing is the mechanism by which independent things become correlated.
• Dependency direction enforced. Messaging must not call the feed. Payments must not depend on recommendations. A static check on dependency direction is the highest-value fitness function here, because critical paths acquire optional dependencies by accident, never by decision.
• Mini-programs as a sandboxed tier with strict resource and time limits. Third-party code inside the product is an availability dependency on software you did not write — it must be bounded, not trusted.
• Notification fan-out physically separated from interactive paths. A broadcast to hundreds of millions is a workload that will saturate whatever it shares.

The property that makes it work at this scale

Cell-based architecture. Users are partitioned into cells, each a full independent stack. A failure is scoped to one cell — a percentage of users — rather than to a percentage of every user's experience.

The distinction matters enormously at this population size. A 2% failure affecting everybody slightly is an event nobody can debug and everybody notices. A total failure of one cell affects 2% of users completely, is trivially attributable, and can be mitigated by moving those users.

The trade-off

Isolation costs money and duplication. Separate infrastructure per capability means lower utilisation, more operational surface, and more deployment pipelines. Cells multiply that further.

The justification is that at this scale, the cost of a correlated failure is not proportional to its technical severity — it is a national-infrastructure event. The isolation is bought not because it is efficient but because the alternative failure is unacceptable, and that is a legitimate and explicit trade rather than an engineering preference.