EVENT ARCH

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.

Event Sourcing

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

Event Notification

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.

Fan out.

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.

CQRS

Yet another thing, see CQRS for a full write-up on this pattern in my own words.