Non functional requirements NFRs:
Consistency (across distributed landscape) (Eventual consistency OK?)
Ownership by single-services (for independent deployment)
Low latency read (responsiveness)
Availability of customer-exposed components
Capabilities of Architecture:
have a single source of true for each type of data, to guarantee Consistency
Components can serve READ independently of each other, to ensure availibility
when one service goes down - the others can use the read-copy of events
use “Aggregates” to define read-copies schemas with multiple entiteis, grouped by use-case
WRITE is served from single sources of true
Capabilities of Event-store:
when service is down, then replay missed events from event store
replay missed events from the beginning of time
create snapshots, to avoid replaying the complete history replay
convert event schemas, to convert old history into new format, when schemas change
Links