Tohuwabohu excorcism

• https://www.designgurus.io/blog/Consistency-Patterns-Distributed-Systems
• https://darshanadinushal.medium.com/rabbitmq-in-event-driven-communication-between-microservices-df3a9c38ece9

Event-store

• Replaying Events in a Microservices Architecture where command and query microservices communicate through RabbitMQ
• Axon Server 4.6 & AxonIQ Conference
  • https://www.axoniq.io/
  • A Guide to the Axon Framework

Non functional requirements NFRs:

• Consistency (across distributed landscape) (Eventual consistency OK?)
• Ownership by single-services (for independent deployment)
• Low latency read (responsiveness)

Capabilities of Architecture:

• have a single source of true for each type of data, to guarantee Consistency
  • e.g. by Entity type?

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

• Traditional applications have often used database transactions to enforce consistency. In a distributed application, however, that's often not feasible. A single business transaction may span multiple data stores, or may be long running, or may involve third-party services. Ultimately it's up to the application, not the data layer, to enforce the invariants required for the domain. That's what aggregates are meant to model.
• Data Consistency Models: ACID vs. BASE Explained
• Challenges and solutions for distributed data management
• Data consistency in microservices architecture
• Migrating to Microservices and Event-Sourcing: the Dos and Dont’s
• Lars Röwekamp über Shared Data in verteilten Architekturen
• https://neo4j.com/blog/acid-vs-base-consistency-models-explained/