principle-event-drivenlisted

# Event-Driven Architecture The log is the source of truth: producers emit immutable events; consumers react asynchronously. This decouples services at deployment and operational boundaries and lets new consumers replay history — at the cost of eventual consistency and significantly more failure surface area than synchronous calls. ## Event Sourcing Store every state change as an immutable event; derive current state by replaying the log. The aggregate's current state is a projection, not the record of truth. - Snapshots cap replay cost: persist a projected state checkpoint every N events and replay only from the latest snapshot. - Projections are disposable — design them to be rebuilt by replaying; avoid hand-rolled caches that drift from the log. - Event store must be append-only; mutating or deleting events destroys the audit trail and breaks replaying consumers. - GDPR erasure: store PII in a side-table and tombstone the key rather than mutating event history. ## CQRS (Command Query Responsibility Segregation) Separate the write model (commands that mutate state) from the read model (queries over projections). Often paired with event sourcing but independent of it. - Read replicas can be denormalized and tuned for specific query shapes without polluting the write model. - Consistency lag between write and read models is a feature contract, not a bug — document the SLA. - Avoid CQRS in simple CRUD services; indirection cost exceeds benefit until query and write shap