Tohuwabohu excorcism

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== distributed_systems =====



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


TOGAF ADM for Microservice Architecture
{{https://s3.eu-central-1.amazonaws.com/alf-digital-wiki-pics/sharex/NNdHXHyfyG.png}}



===== Event driven architecture =====


Event-store

  * [[https://groups.google.com/g/axonframework/c/-OQK2UDIHAE?pli=1|Replaying Events in a Microservices Architecture where command and query microservices communicate through RabbitMQ]]
  * [[ https://www.youtube.com/watch?v=OYQE5fvgxU0 | Axon Server 4.6 & AxonIQ Conference]]
    * https://www.axoniq.io/
    * [[ https://www.baeldung.com/axon-cqrs-event-sourcing | A Guide to the Axon Framework]]


==== Data ====


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**
    * e.g. by [[https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd|Entity type]]? 
  * 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
    * use SAGA pattern on "Aggregates" and **synchronous dependency** on "single source of true APIs" to ensure consistency
    * 


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

  * [[https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd|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.]]
  * [[ https://neo4j.com/blog/acid-vs-base-consistency-models-explained/ |Data Consistency Models: ACID vs. BASE Explained]]
  * [[ https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/distributed-data-management | Challenges and solutions for distributed data management]]
  * [[ https://medium.com/@ggonchar/data-consistency-in-microservices-architecture-bf99ba31636f | Data consistency in microservices architecture]]
  * [[https://hackernoon.com/migrating-to-microservices-and-event-sourcing-the-dos-and-donts-195153c7487d|Migrating to Microservices and Event-Sourcing: the Dos and Dont’s]]
  * [[ https://www.youtube.com/watch?v=BCqZuYZ21OA | Lars Röwekamp über Shared Data in verteilten Architekturen]]
  * [[ https://neo4j.com/blog/acid-vs-base-consistency-models-explained/ | ]]