event_sourcing complements database_per

event sourcingComplementsdatabase per service

Source: Pattern·Target: Pattern

Summary

Event sourcing and database-per-service reinforce each other: each service owns its event log and materializes its own read models independently, with cross-service data sharing happening via published events rather than shared database access.

Evidence

·Database-per-service eliminates shared schema: services can only share data by publishing events
·Event sourcing provides the natural mechanism for those published events: each service emits domain events from its write side
·Cross-service queries are replaced by event-driven projection updates: eventual consistency is the explicit tradeoff
·Martin Fowler's Microservices article identifies this combination as the canonical data management pattern for microservices
·Netflix's microservice architecture uses event sourcing per bounded context with Kafka as the event backbone

Operational Context

·Each service's event log is its private source of truth: other services consume events, not the log directly
·Event schema contracts between services must be versioned and backward-compatible
·Saga pattern handles multi-service business processes in this architecture

Tradeoffs

·Cross-service queries require eventual consistency: no joins across service event logs
·Event schema versioning is a distributed coordination problem: schema changes require coordinated deployment
·Debugging cross-service workflows requires distributed tracing (correlation IDs across event boundaries)

Evidence grounding

Grounded, 5 supporting items

The combination of event sourcing and database-per-service is the cornerstone of event-driven microservices architecture, documented by Richardson, Vernon, and Young in the DDD and microservices literature.