Mam parę pytań o event sourcing, ponieważ to hasło znam głównie nazwy, z tekstów na stronach. Generalnie o event sourcing w ogóle nie myślę na co dzień, ale również coraz cześciej spotykam coraz więcej haseł, które nawiązują do event sourcing i chciałbym chociaż trochę (poprzez tą dyskusję) zrozumieć podstawowy tok rozumowania, jaki prowadzi do tego, by w projekcie zastosować event sourcing.
Zebrałem kilka pytań, jakby ktoś mógł na nie odpowiedzieć to byłoby super :)
-
W jakich okolicznościach zrodziła się ta technika? Jaki główny problem miała rozwiązać?
-
W jakim momencie zaczyna się event sourcing? Czy np jak mam usługi, które komunikują się poprzez wysyłanie wiadomości po kolejce (zamiast przez bazę) to już jest event sourcing?
-
Na niektórych stronach event sourcing trochę sprowadza się do budowania pipeline i nie rzadko przy użyciu funkcyjnych języków. Dlaczego oprogramowanie zmierza w tym kierunku? Domyślam się, że pipeline łatwiej się skaluje, bo dokłada się kolejne workery, ale czym to różni się od typowego skalowania? Chodzi o jakąś kompozycyjność, której nie dostrzegam?
-
Z event sourcing trochę powiązana jest wzorzec/technika CSRQ. Tzn osobno projektujemy zadania do odczytu, osobno do zapisu. Z czego to tak naprawdę wynika, co tracimy/zyskujemy idąc w CSRQ? Chodzi o to, że odczyty są ze slaves, a zapisy lecą do mastera?
-
Kiedy event sourcing bardziej przeszkadza niż pomaga? Jakie nowe problemy wprowadza ta technika?
-
Ostatnie hasło jakie kojarzy mi się z event sourcing to bitemporal. Rozumiem, że jakaś baza wtedy ma wgląd do historycznych danych, tzn nie nadpisuje starych danych, lecz tworzy nową wersję - w czym to jest lepsze od postgresql i robienia insertów zamiast updateów?