There are at least three meanings to separate: field absent means leave it alone, explicit null means clear it, and a concrete value means replace it. The consumer may deserialize the sparse event into a full customer object, read a default null for the missing address, then send a whole-document replacement to search. Or it may construct a patch with address: null, which under JSON Merge Patch means removal. The source did not ask for either operation. The mistake is at the conversion between the source event's presence semantics and the index write's semantics.

I would inspect the raw event, its schema, the deserialized representation and the exact outbound index request for one affected customer. Do not infer intent from a language getter that returns a default value when a field is missing. Protocol Buffers' field-presence guidance explains why an implicit-presence scalar cannot always distinguish an unset field from one explicitly set to its default. For partial updates, use explicit presence, a field mask, or an operation format that can express leave, set and clear without ambiguity. If the source publishes full snapshots instead, say so in the contract and replace the whole document only from a complete authoritative snapshot.

Then think about ordering. A delayed name patch must not overwrite a newer address update with an older snapshot. Store source revision or per-field version information as the domain requires, and make replay idempotent. Test omitted, explicit null and concrete address values through serialization, index write and query visibility. A search result showing the old address for a short refresh interval is a different problem from the address being durably erased.

The interview decision is whether the event stream carries patches or state snapshots. Treating one as the other can silently destroy correct data at scale, even when every consumer reports successful processing.