Zrozumienie zasad EDA

Event-Driven Architecture has services communicate by producing and consuming events — reactions to things that happened. You get decoupling, scalability, and responsiveness.

An event is a record of something that already happened, like "OrderPlaced." It's immutable, timestamped, and carries the data describing what occurred.

Event Sourcing stores state as a sequence of immutable events. Instead of just the current balance, you keep every deposit and withdrawal that led to it.

With event sourcing, you rebuild current state by replaying past events in order. Apply every deposit and withdrawal and you get the balance — plus a full audit trail.

Event Sourcing hands you a full history of changes: complete auditability, time travel to any past state, easy debugging, and replayable decoupled events.

CQRS separates the model that updates data (commands) from the one that reads it (queries) — think two structures, one tuned for writes, one for reads.

In CQRS, commands modify data through the write model and queries fetch it through the read model. Each side is optimized for its one job.

Eventual Consistency means that with no new updates, all reads eventually return the latest value. Not "always consistent" — "eventually" consistent.

Strong consistency everywhere is slow and complex. Eventual consistency trades it for availability and speed — like a social feed that briefly lags, then catches up.

Które z poniższych stwierdzeń dotyczących zasad architektury sterowanej zdarzeniami (EDA) są PRAWDZIWE?

You've got the core EDA principles: event sourcing (changes as events), CQRS (split read/write), and eventual consistency. Nicely done.