Profile writes are shared-state engineering
Multiple writers turn the profile into shared operational state.
Generic diagram. It does not reproduce a client architecture.
When several processes write to the same profile, the target dataset, the write order and the handling of empty values stop being configuration details. They become architecture decisions with silent-corruption risk.
The answer is bounding who writes where, declaring the semantics of each update, and keeping history out of operational state.
Production signals
- Attributes disappear some time after the update.
- Two processes write to the same dataset.
- The written value is nowhere it could be rebuilt from.
Recommended architecture
Declare per field who writes, with which operation, and what an empty value means. In arrays the intent is explicit, append or replace.
Send the event separately if you want an audit trail, because a profile write does not always leave one in the lake.
When not to apply it
- Do not create profile state for request-only data.
- Do not clear a field by touching one identity, because a non-null value on another wins again.
Try it in a simulator
Interactive scenarios where this pattern fails and gets fixed.