I write here “event arch”, because “event-driven architecture” and “event sourcing” are too vague. There’s also loosely-related architecture topics on messages, queues, and whatnot.
Putting it all here.
Basically, using an event-driven architecture in which each event represents a state change, and each state change is recorded into the data persistence layer. Application state is entirely reconciliable by replaying past events.
Relevant video: Martin Fowler on Event Sourcing
This is totally different from event sourcing, this is essentially: event-driven architecture using a fan-out strategy. Like, for example “order created” event which any number of consumers can subscribe to and respond. The publisher does not care who the consumers are or what they do, it just publishes an event, anyone can subscribe.
Event-Carried State Transfer
This is actually what we’re doing at Italic with our new order processing pipeline. Events are published which are basically commands.
Yet another thing, see CQRS for a full write-up on this pattern in my own words.