# Propagate Identity Changes Without Shadow Profile Sprawl > Send minimal identity events and read current details on demand so downstream services copy only fields they truly own. Canonical URL: https://www.devobs.io/articles/identity-events-without-profile-sprawl/ By: Elias Brooks Published: 2025-05-18T04:52:07.945Z Updated: 2026-09-06T10:18:15.722Z Section: Identity ## Publish identity references instead of whole profiles Downstream services should store an immutable identity reference plus fields required for their own business rules. Publish small change notifications and let consumers fetch current details when freshness matters, instead of broadcasting complete profiles everywhere. Use stable identity references and publish only the change metadata consumers need. ## Limit events to consumer-owned fields A billing service may own customer ID and invoice address because it must issue invoices; analytics may need only a pseudonymous subject and region. Emit identity ID, event type, changed-field names, revision, and time. Avoid putting secrets or full traits into the envelope. [CloudEvents Specification](https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md) provides the complementary protocol or operational detail. ## Separate reference data from owned data Use the OpenID Connect issuer and subject pair as the durable external identity reference; the [OpenID Connect Core specification](https://openid.net/specs/openid-connect-core-1_0.html) defines subject identifiers within an issuer. A billing system may legitimately own invoice name and address, but an analytics consumer rarely needs the authentication profile. Events should state identity reference, event type, changed field names, revision, and occurrence time. Consumers fetch current authorized details when necessary. Do not put recovery addresses, credentials, or a complete trait object into a durable event merely for convenience. ## Make deletion and replay predictable Classify every local field by purpose, source, freshness, retention, and deletion duty. A consumer that copies a field becomes responsible for correcting and deleting it. Process events idempotently by identity and revision; ignore an older update that arrives after a newer one. Test duplicate delivery, missing revisions, a delayed rename, deletion followed by replay, and loss of access to the profile API. Maintain a consumer inventory so a deletion request reaches dormant projections and exports. Begin with one identity event and remove every attribute whose consumer cannot name a current business rule; keep only the stable reference and change metadata needed to recover. ## Source references - -