Vortrag 4 Notizen - Archi-Lab/fae-team-3 GitHub Wiki

Nur synchron schlecht. langsam und brüchig

problem sind chains of services. ein ausfall kann einen ganzen request zerstören. das kostet zeit

mitigations:

• retry
• timeout
• fallback
• circuit breaker

Es ist nicht Perfromadn, solche ketten zu bauen, kostet viel Zeit.

mitigations:

• paralleliseriung
• chaching

Daten selber verwalten. Dann sind keine weiteren anfragen nötig. kann asynchron stattfinden.

Besteht logisch aus 2 Teilen:

• Domain Entity
• State change

functional objekt describes domain change.

a vehicle for DB replication

Jedes event hat eine eigene id.

Weiterer Inhalt:

• Key
• Version
• time
• type
• payload

Keine Deltas, immer komplette Entity (Bei event streaming/sourcing könnte man deltas nutzen)

Man kann alles behalten, oder nach einer gewissen zeit löschen aus der queue.

Ein event ersetzt ein get. und ist kein Befehl.

REST muss weiterhin existerien. und wird genutzt für befehle und dergleichen.

event muss self contained sein. (keine REST links in events)

transaktional vollständig, also unabhänigkeit von der reihenfolge der events.

nach jedem event soll das system in einem konsistenten state sein,.

vollständige verarbeitung der events.

only true facts must be published, meaning, only saved existing data.

erst verarbeiten, dann ein commit ok senden.

wenn unter element entities sich ändenr, sollte die root komplett publizierd werden.

eventual consistency, time critical data.

bei time sensitive stuff: > no events, direkt calls so correkt data exists definetly.

API sollte von anfang an komplett definiert werden.

schnell, ausfallsicher, open source

• Producer
• Consumer
• Stream
• Connect

Topik ist event queue. hat partitionen. keys sdni aufsteigend konsistent

Log compaction ->only the most recent version stays, all others get removed.

Es ist aufwenig, ein topic zu betreiben. sparmsam.

Only one content produces one topic

Neu publizieren der gesammten topic sollte möglich sein, auf befehl, falls kafka ausfällt.

producer has to make shure, the message got delivered and write the commit.

Idempotent. reconsume all events from beginning, also to build copy data base.

manual commit after prozessing of an event.

error repository for all problem events. muss regelmäßig kontrolliert werden. womöglich mit anderen teams reden.

events können auch öfters zugestellt werden können, mit key value store könnte man das mitigieren

jede instanz sollte jede message bearbeitung können.s