Event Sourcing vs Messaging

TL;DR

Explanation

Event sourcing: the event log IS the database — current state is derived by replaying events. No UPDATE/DELETE, only append. Benefits: full audit trail, time travel, event replay, projections. Kafka can serve as the event store. Messaging: events are transient notifications between services — usually not the source of truth. Combining: store events with event sourcing (for your domain), publish to a message broker for other services. CQRS + Event Sourcing: command side appends events, query side builds projections from event stream. PHP: EventSauce, Prooph, Broadway libraries.

Common Misconception

Why It Matters

Common Mistakes

• Using event sourcing where a simple audit log suffices — add complexity without benefit.
• Not versioning events — events are forever, schemas change.
• Event sourcing without CQRS — query performance degrades without read projections.

Code Examples

// Treating messaging as event sourcing — no persistence:
$broker->publish('user.updated', $event); // If broker goes down, history lost

// Event sourcing — events ARE the state:
$user->applyEvent(new UserEmailChanged($userId, $newEmail));
$eventStore->append($user->getDomainEvents()); // Persistent, immutable

// Then publish to broker for other services:
foreach ($user->getDomainEvents() as $event) {
    $broker->publish($event);
}

References

• ↗ https://martinfowler.com/eaaDev/EventSourcing.html

Tags

Related Terms