If you’d like to know why you may not need snapshots and learn modelling patterns to do #EventSourcing efficiently, read my latest article on @eventstore blog 👇
It may sound blatant, but I think that there are not many resources like that on this topic 1/ eventstore.com/blog/keep-your…
It’s a looking article, much longer than the length of the streams you should keep in the event store 🙂 I tried to keep it shorter or split it, but my main goal was to provide a thorough, nuanced and complete explanation. So grab a glass of preferred drink and have a read 2/
This is the third part and (hopefully) the last one of the triad about temporal modelling patterns. I started with a general introduction, explaining closing the books as to why you should reconsider your decision about snapshots. 3/ eventstore.com/blog/snapshots…
Then I explained snapshotting strategies. All patterns may be useful in a specific context. I don’t recommend snapshots as a first design decision, but if you have to do it, then do it right. I explained what options you have 4/
And now I’m coming with a grand finale, to give you tools to keep your stress short. It’s essential to use event stores efficiently. It might not be evident if you’re coming from the streaming world. They can keep streams long, as you’re not reading from them, but... 5/
...just receiving notifications. In Event Sourcing, you treat your events as the source of truth, and you should read stream events to make decisions on the latest state. Read more on that in: event-driven.io/en/event_strea….
It’s important to not copy/paste patterns /6
If you model your streams correctly and keep them short, you’ll have a much easier life. It’ll spare you a lot of troubles around versioning, performance, operation etc. I’m not saying that’s easy, but that’s the reason why I wrote this lengthy article and Twitter thread 😅 7/
This article is extremely important for me. I put huge effort and been probably too long in this rabbit hole for too long not seeing the light. So I’m happy that’s out, and we’ll be even more pleased if you read it and send me a feedback! 😀 8/
Last but not least, I thank the draft readers for their precious feedback. Not all suggestions I could apply, but it helped me a lot.
Thanks go especially to @rbartelink@mat_mcloughlin@alchemist_ubi@wastaz@aludwikowski, but also to the others! You rock! 🤘😀🤘 9/9
Of course, I had to forget about someone, but at least you have a personal thank you tweet @RadekMaziarka 😅 Thanks for the precious feedback! 10/10
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@bitbonk@bitbonk good question! Indeed, the IoT model seems to be aligned with Event Sourcing, as we're listening for the events and then doing interactions. The main issue is the nature of data coming from machines and the frequency. In Event Sourcing events gather business value 1/
@bitbonk IoT data is usually raw. Also, the number of measurements and their frequency can be really high, especially for the really busy production line. Most of the event stores are not so lightweight. So they not always can be run on e.g. raspberry pi. 2/
@bitbonk Also, quite often, they have a bigger frequency than event stores can handle per second. The common pattern is to do the data ingestion. So using lightweight, but fast type of storage (e.g. key/value) or queue that will batch the events from IoT, group and change into events /3
@mzagozda Dziękuję bardzo! Cieszę się, że się podobało 🤩 Bardzo dobre pytanie.
Zacznijmy od tego, że sam Event Sourcing jest wzorcem, który co prawda o tym mówi, jak przechowywać dane, a w zasadzie nie tyle jak co w jakiej formie - konkretnie zdarzeń. Jednak sam w sobie nie mówi gdzie 1/
@mzagozda Zatem moglibyśmy przechowywać te zdarzenia równie dobrze w pliku tekstowym, binarnym, excelu, xmlu, json, czy też już bardziej rzeczywiście w bazie danych. No i tutaj w zależności od tego jaka jest charakterystyka naszego miejsca przechowywania takie mamy też możliwości 2/
@mzagozda Jeżeli korzystamy z jakiegoś rozproszonej bazy danych to może to być faktycznie utrudnione. Większość z nich ma możliwość tylko "symulowania" takiej weryfikacji (np. DynamoDB aws.amazon.com/blogs/database…). Zwykle jest to przy symulowane poprzez algorytmy rozwiązywania konfliktów /3
@HaripraghashS@HaripraghashS 2 short questions without 2 short answers 😅But let's try! Projections for me when I started my journey with #EventSourcing was the hardest thing to understand. I thought: ok, I can rebuild the aggregate state by replaying events one by getting them by id 1/
@HaripraghashS Having that I'll have the state of the single aggregate. Wait a minute! If I won't to do that for the aggregate list then I'd need to get all events for those aggregates and reply it one by one? Nah that's can't be! For that we have we have projections. As you for sure know /2
@HaripraghashS What are projections? It's just representation and interpretation of the set of event. What's more when we're replying events to get aggregate state - that's also projection. It's easy to forget about that because it's default case. We're just interpreting events to get state /3