A system originally identifies `User` entities by email address (using the email as the natural key/identity). Later, the business adds an 'email change' feature. What breaks because of this identity choice, and how does a surrogate key like a UUID fix it?

## The promise a natural key quietly makes An Entity's identity is supposed to be the one thing about it that never changes for its entire lifecycle — everything else is allowed to mutate precisely because the identity anchors 'this is still the same thing' through those mutations. The moment a team picks a business attribute as that identity — email, username, SSN, a license plate — they are implicitly promising that attribute will never change for the life of the entity, and almost no real-world business attribute can honestly make that promise. **Email is a particularly common and particularly bad choice** because 'change my email' is one of the most ordinary account-management features a system can have, yet a natural-key design makes that ordinary feature catastrophic at the identity layer. ## What actually breaks Mechanically, here's what breaks. - **Deleting the old identity.** If `User` rows are keyed by email in the database, updating a user's email is not an UPDATE of one field — it is, from the identity model's point of view, deleting the old identity and creating a new one, because 'the user with email X' has ceased to exist and 'the user with email Y' has begun to exist. - **Every referencing table.** Every other table with a foreign key referencing the old email either needs a coordinated cascading update across every table (expensive, error-prone, and impossible to do atomically across service boundaries in a distributed system) or is left pointing at a row that no longer matches anything, silently orphaning orders, audit log entries, permission grants, and support tickets. - **External systems.** External systems that received a copy of the email as a join key (an analytics warehouse, a billing provider) don't get the memo at all unless there's an explicit synchronization event, so they permanently diverge, misattributing the user's future activity to a phantom 'old' identity. - **In-flight requests.** Session tokens or password-reset links that embed or hash the email similarly break for any in-flight request that started before the change. ## The surrogate-key fix The fix — a surrogate key, typically a randomly generated UUID assigned once at entity creation and never altered — exists precisely because it separates two concerns that natural keys accidentally merge: | The concern | Its phrasing | Its nature | |---|---|---| | identity | 'which record is this' | permanent | | attributes | 'what does this record currently say' | mutable | Every foreign key, cache entry, and external reference points at the UUID, which is completely indifferent to the user changing their email, name, or phone number — those changes become ordinary UPDATE statements on non-key columns, with zero cascading effects. Email retains an important role — it's still how a human logs in — but that's now a lookup index (a unique index on `users.email`), not the identity itself; the lookup index can be dropped and rebuilt on a new value trivially, whereas identity cannot. ## What the surrogate key costs The trade-off of surrogate keys is mostly usability and readability, not correctness: - UUIDs are unwieldy to type, log, or debug by eye compared to a human-readable natural key, and if a system exposes raw UUIDs in URLs it can look unpolished (mitigated by adding a separate, still-mutable-if-needed 'slug' or 'handle' distinct from the true identity). - There is also a genuine design question about whether a natural key can ever be trusted — some values really are effectively permanent by strong external guarantee (an ISO country code, a well-governed product SKU under strict change control) and using them as keys is fine; the risk is specifically attributes the business itself allows end users or admins to edit through an ordinary feature. ## The migration teams end up paying for A well-known real-world instance of exactly this bug class: early versions of many web applications used username or email as the primary key for user accounts, and adding a 'change username' or 'change email' feature years into the product's life became a surprisingly large, risky migration project — every foreign key across dozens of tables, every cache key, every external integration had to be audited and migrated to a newly introduced surrogate id before the 'simple' rename feature could ship safely. Teams that have been through this once tend to treat 'always give every Entity a surrogate identity at creation, never derive identity from a mutable business attribute' as a hard rule from day one, exactly because retrofitting it later is so much more expensive than establishing it upfront.