Skip to content

CONCEPT Cited by 1 source

Identity decoupling (user ID vs profile ID)

Separating the internal user entity (the complete record: legal name, email, phone, account state) from one or more public-facing profiles (context-scoped subsets of that record). Each user has exactly one internal User ID; the same user can have many Profile IDs, each scoped to a specific context (a product surface, a role, or a single event).

The property that matters is that the identifier types are distinct, not just the payloads. Mixing a User ID and a Profile ID becomes a type error caught by the compiler / linter, which is what makes the privacy guarantee hold up under normal feature velocity.

Why decouple

  • Context-awareness. A profile is only visible where it's relevant (e.g., co-guests on one Experience can see Marie's Profile B for that Experience, but not her profile on a different Experience).
  • Cross-context unlinkability. Because the external identifier differs per context, it becomes structurally harder to link the same user across unrelated contexts — e.g., "is this private guest on Experience X the same person as that host of a cabin in the Alps?" The system doesn't expose the join key.
  • Per-context opt-in. Users can opt into visibility on one context without leaking identity into every other context. Enables real per-event privacy, not just global on/off.
  • Role separation. Host and guest representations of the same person stay unlinked to external observers by default.

Implementation notes (from sources)

  • Enforce at the type system. User IDs and Profile IDs are different types so code can't silently mix them. Strong typing + linters + code review act as the migration safety net.
  • Enforce at the data layer. Decoupling identifiers doesn't help if the wrong one leaks through an API — an authorization substrate (e.g., systems/himeji) has to check access at data read time.
  • Materialize new profiles at event boundaries. Airbnb creates a fresh per-Experience Guest Profile when a guest books an Experience; visibility rules live with the Profile, not the User.
  • Migration is the hard part. Rolling out a new ID discipline in a large codebase is an audit-and-refactor exercise: locate every data-access site, map each site to an owning team, manual-review for context, AI-assisted refactor with humans in the loop, and rely on types + tests to prevent regressions.

Seen in

Last updated · 200 distilled / 1,178 read