A product with 2 million accounts in one region opens a second cell in-country for one market next quarter. Roughly 8% of accounts move to it. No code changes are planned beyond routing. Which thing breaks on the day the second cell goes live?

What is being tested

Whether you can see that splitting by jurisdiction turns global invariants into distributed ones, and that the first thing to break is a correctness property nobody wrote down.

The mechanism

A unique index on email is enforced by one database. Put 160,000 accounts in a second database and that index now covers 8% of the population. The same person can hold an account in each cell, with different passwords and different data, and neither cell is wrong: the constraint simply no longer exists. Nothing errors, so nothing alerts. It surfaces weeks later as a support ticket about a password reset that resets the wrong account, or as an erasure request that deletes one of two records.

The same break hits every other global invariant quietly: idempotency keys scoped per cell, so a retried payment can be accepted twice; order and invoice numbers that must be unique for tax purposes; any counter a partner reconciles against.

Why the other options fail

• Double-counted reporting. Real, and a derived-data problem you fix in one pipeline. It does not corrupt the source of truth.
• The mobile base URL. A genuine piece of work, done once, with a routing service or a home-cell lookup at login. It fails loudly during testing rather than silently in production.
• Support access becoming a transfer. True and important, and it is a paperwork and access-control change on a known date, not an invariant that disappears without notice.

The two fixes and their costs

1. Scope uniqueness to the cell and accept that one person may hold two accounts. Cheap and honest. The price is that account merge, billing identity and erasure become per-cell operations, and your support tooling has to show both.
2. Keep a global directory with no payload: a salted hash of the email plus the cell id, so sign-up can ask "does this identity exist elsewhere" without the other cell's data leaving. That directory is itself personal data, so it needs its own basis and its own location decision, and it becomes a dependency on the sign-up path. Keep it to two columns and cache negatives.

Pick the second only when a duplicate account causes real harm, such as a regulated single customer view or an entitlement that must not be claimed twice.

When not to split at all

Before building a second cell, get the requirement in writing: storage in-country, processing in-country, or no foreign access. If the rule is storage only and the volume is modest, a single region with contractual controls, in-region backups and a restricted support path is often compliant and an order of magnitude cheaper to run. Two cells means two deploy targets, two on-call rotations, drift between them and every cross-cell feature becoming a distributed problem. The trigger to split is a written obligation that a contract cannot satisfy, not a customer's preference for the word "sovereign".