'Event-driven architecture' covers two distinct patterns that get conflated. Event sourcing: persist state changes as events; current state is the fold of all events. Event streaming: publish events for other systems to react. Some systems do both; many do only one. Knowing the difference avoids architectural mismatches.
Event sourcing
The events ARE the database. Instead of UPDATE user SET balance=100, you append BalanceCredited(amount=100). Current balance = fold over all events for that user. Time-travel queries (state at any timestamp) come free. Used in banking, ledgers, regulated audit trails.
Event streaming
Events are published to a broker (Kafka) so other services can react. Source service still uses traditional DB for its own state. Consumers materialize their own views from the stream. Used for cross-service integration, microservice decoupling.
When to use each
| Need | Sourcing | Streaming |
|---|---|---|
| Full audit history | YES | Partial |
| Multi-service integration | Possible | YES |
| Cross-system replication | Hard | YES |
| Complex aggregate ops | Hard | YES (via Kafka Streams/Flink) |
| Time-travel queries | YES | NO |
Combining them
Many systems source events into Kafka via CDC (Debezium) — write to DB normally, CDC produces events for consumers. Best of both: traditional CRUD UX, event streaming for integrations. Not pure event sourcing but practical.
Anti-patterns
Using Kafka as the only source of truth without event sourcing → topic retention deletes your data. Using event sourcing without a snapshot strategy → fold-from-zero takes hours after N years. Define snapshots if events accumulate.