Differences

This shows you the differences between two versions of the page.

--- software_architecture:distributed_systems [2024/01/12 20:24] – skipidar
+++ software_architecture:distributed_systems [2025/03/24 07:01] (current) – skipidar
@@ Line 1: / Line 1: @@
 ===== 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/ | ]]