City asset inventory consumers need timely notice when an asset record changes, not only a nightly warehouse refresh. Which movement pattern fits?
Select an answer to reveal the explanation.
Short Explanation
If the hydrant map changes at noon, waiting for tonight’s batch is like reading yesterday’s weather for today’s storm. Event-driven movement tells consumers when something changed so freshness matches the job.
Full Explanation
Consumers who need timely notice when an asset record changes—not only a nightly warehouse refresh—need event-driven data movement so interested systems receive change notifications when freshness requires it. Relying solely on annual archive tapes fails operational consumers. Blocking all change data capture because ETL schedules are simpler to ignore rejects a needed pattern. Publishing changes only inside locked weekly PDF attachments is not integrable eventing. Exam pattern: event-driven movement for change notification. Caveat: events need schemas, keys, and access control so asset changes do not leak sensitive details to unauthorized subscribers. Operationally, publish an asset-change event contract, onboard one consumer that previously waited on nightly refresh, verify notification latency meets the requirement, and monitor dead-letter and schema-evolution handling. Monitor event schema compatibility and subscriber lag so asset-change notifications remain timely without breaking consuming civic systems. Choose event keys that match governed asset identifiers so subscribers can join notifications to catalogs and operational systems without inventing parallel identity schemes.