Event sourcing persists every application-state change as an immutable, ordered event rather than overwriting the current state. The event sequence becomes the source of truth, and consumers reconstruct current state by replaying it from the beginning. section 1.7.2
A Kafka-based event-sourcing design typically involves these choices:
- Retain the event log indefinitely so services can replay historical changes and rebuild state in memory or a local database. section 1.7.2
- Treat Kafka as the definitive event history while allowing downstream services to maintain materialized state for operational use. section 1.7.2
- Use snapshots when replaying the complete history would create restoration bottlenecks for consumers. section 7.6
- Consider tiered storage for older events, but account for storage cost and the performance consequences of loading data on demand. section 7.0
Customer addresses and orders
CustomerService emits address-update events. A consumer replays the address log to reconstruct each customer’s current address, while an order-processing application joins orders with that change-log topic to enrich them with address data. section 1.7.2
Event sourcing does not eliminate databases: queries such as finding addresses near a location require consumers to read, deserialize, and process broker messages. Kafka fits the pattern because its durable, replicated commit log preserves historical events, but snapshots and query-oriented state remain important design concerns. section 1.7.2 section 1.7.3
