Event Sourcing

Instead of storing just the current state of the data in a domain, use an append-only store to record the full series of actions taken on that data. The store acts as the system of record and can be used to materialize the domain objects. This can simplify tasks in complex domains, by avoiding the need to synchronize the data model and the business domain, while improving performance, scalability, and responsiveness. It can also provide consistency for transactional data, and maintain full audit trails and history that can enable compensating actions : Event Sourcing pattern - Azure Architecture Center

Context and problem
Most applications work with data, and the typical approach is for the application to maintain the current state of the data by updating it as users work with it.

CRUD (create, read, update, delete) approach has limitations in a domain-driven architecture and in a collaborative domain with many concurrent users : slowing down performance and responsiveness, update conflicts, additional auditing mechanism to add, etc.
Solution
The Event Sourcing pattern defines an approach to handling operations on data that's driven by a sequence of events, each of which is recorded in an append-only store. The events are persisted in an event store that acts as the system of record (the authoritative data source) about the current state of the data.

Event Sourcing pattern with materialized view in Integration Layer
Challenges

Delay between the event store and the publication in the integration layer (topic/message).
Data in the event store could be a raw data and make the consumer to increase a work of interpretation.
Difficult to combine existing events in the store with the new version if we have to do a migration to the event store.
Even though this pattern minimizes the chance of conflicting updates to the data, the app must still be able to deal with inconsistencies that result from eventual consistency and the lack of transactions.