 Hello everyone. Hello, Thailand. And I want to say that we did it. It's my second time in Thailand and the first time in Bangkok. And yesterday we tried to install PartyGem and I found it. And I'm not sure that I really want to install it. So it's not the first trip to Asia for me. And that's why I really know what is jet lag. And it's every time hard because I have no idea wake up at 4am or go sleep at 3pm. And yesterday, yesterday I was inspired by team. I really love this game. And I tried to find something in the internet. But unfortunately I found nothing. And I thought, okay, maybe a quest of Rubyist. It's super complicated for Google. And I tried to find Rubinia. But unfortunately I'm not sure that it will be useful for me. So, okay, my name is Anton. I am from Moscow. You can find some contacts. And also I'm top Talbot counter-architecture. And that's why I can use this meme. It's my favorite meme about architects. Someone know me as a guy who work on Hanami. And it's true. So, I really love open source. Also now I'm dry core developer too. A little bit because I know Piotr. And Piotr know me. Sometimes I make streams on Twitch. And usually you need to know about me something. I really love stickers. And I have a Durian sticker. And I really love some Donor or Burrito. I have a proof of photo. It's me in Minsk. It's near with Russia. I'm eating Burrito. And I really love this photo because on this photo I look like a person who goes to some Japan TV show. And if you want to talk with me, we can talk about coffee, beer, psychology. I have Nintendo Switch, 3DS. And I really love to draw some images from my presentations. And the first one was drawn by me. And also I really love stories and bad stories. And I try to write something and make a really good story. I expected that I'll be like this guy. But unfortunately, reality was a little bit different. And I'm a lucky person because I got a help from my friend. I really love him. His name is Georgi. And he is really quiet and loves to ask sometimes some questions. And also he is a flower. So the title of my talk is Events. We discuss after party. And now we will discuss events in general. We have a real world and in the real world we have a lot of different events. It can be anything. And sometimes as a developer we need to catch it and do something with it. For example, we have a guide. Who knows what is it? Okay. So in Git we can say that each commit is something that happened. And for example, I have Hanami contributions application. We have a list of commits. It's something which was happened with this repository. And each commit contains description and changes and some meta information. And for example, if we open any commits from this repository, we will see that something what happened. It's the name of this commit. We have a pilot like a change of files and the lines of these files. And also we have a meta information like when, who, and et cetera, et cetera. Another example of events is what happened with the user who tried to buy something. In your commercial application we need to track what exactly he added to order or maybe what deleted from this order. Also, sometimes we need to work with activity audit. And my favorite part is don't delete deleted data. Who have this field in database. So unfortunately in our applications we work with the current state. It means that we need to know what happened with our application on current moment. Not in the past, not in the future, only in current moment. And in this case we can say that our events, it's our actions when we call some controller actions or something like this. And our current state is our data in database. It can be different databases. The most important is that we store current data in database. And so I really love Jirpages, that's why I made it like a Jirpages. And Georgie asked what we'll do if we change it a little bit and start storing events instead of current data and make something like it. In this case we will get event sourcing. And today we will talk about event sourcing in general. And the first rule of event sourcing nobody know about event sourcing. The second rule of event sourcing is you need to store what happened with your application or maybe some aggregate or domain logic instead of storing current state. And after that you can take specific state only when you need it. So the first question if you can ask where we can store something, where we can store this list of events or chain of events. And in event sourcing we have event storage and event storage can be anything. It can be Redis, it can be Postgres, Datomi, Kafka, MongoDB, Oracle, etc. And event storage has some rules. The first one event happened and it was some time ago. We have no idea how many time ago it was, but it was. So the next rule is immutable events. It means that we can't update or change or delete or do anything with event. We can adjust, create one and so on. And in this case we really can delete or update event. And for example we have event store, it's a list of something. And we put, so how it works with event storage in general, we have events of storage, we put some event. For example, user created with some name. After that we say, okay, we need to update user, update his name to something else. And it's how it works. We can't go back and change something in the past, but we can create something new in the current moment. The next problem and the next rule of event storage is we need to work only with valid data in events. It means that we have a client, we have web application and some database. We try to send event. In our web application we start with the data. And if everything is okay, we can store it and say, okay, we can store this event. Or we need to write exception, response error or something like this. The second rule is data evolution. And what does it mean? It means that we have event store and we try to put some event like a first name. It's something. We need to remember that we have a first name, but in future our manager told us that we need to store, not a first name, we need to store full name. And we can't delete or update previous events and it means that we need to remember that we need to update some, we need to work with different data schemas of events in the same time. And that's why we need to remember about data evolution. Yep, we can break the application and to prevert this stuff, we can use specific techniques. For example, we can use optional fields. We can use binary data structures with compatibility levels like AVRA or something like this. And more examples you can find in this really good book. Who knows what this book? So, okay, if you're interested in data and some distributed applications, I really recommend this book. We will talk about this book a little bit more in this talk. And the next question, how we can get state from event store? We have event store with some list of events and now we need to take state. And we can calculate it. And for calculated it, we can use projections. And usually projections is a function which take projection. It's same as a block or same as a block, and we put a list of events and initial state and calculate some specific state. And in this case, project function is pure function. And it's extremely similar to each with object because each with object works like this. And we can change project function to something like this. And it's absolutely same. And how it works? We have event store. We put the first event when user created with some specific name. After that, we create one more event that user was updated. And we start to calculate the state of this user. And for this, we go to the first event, try to find something. We find that user was created with specific name. Go to the next event, and next, and next, and next. And after that, we will see that user updated his name to something else. And the problem is that it looks really slow. And we need to recalculate current state every time when we call this stuff. And yes, we can store events last 10 years, maybe 2 years. We can have a lot of different events. And it can be really hard to calculate it in Ruby or maybe in other different languages because it's performance issues. But we can fix it. And for fixing it, we can use abstraction with call it streams. And how it works? For example, we have two different ice buses. And we have a lot of events for each bus in this case. And for example, we have two events for first bus and three events for the second one. And each bus has an identity number, like number one, number two, or something like this. And we can say that, A, I want to put all events related to the first bus in a specific stream. And after that, I can just take only related to these bus streams and make same stuff for the next one. In this case, we will take less events for processing. And instead of processing all events from database, we can process only 10, maybe 20 events for a specific aggregate. And also, we can make a parallelization for calculations in the state and start a calculation state for two different aggregators in the same time. But the problem here is we need to introduce one more abstraction. And the next idea, how we can improve this idea with getting state, we can create a snapshot of the current data state. And for example, we have a projection function. It's a pure function. And the idea here, we can put any state into state attribute. It can be empty state or it can be some pre-calculated state from the past. And how it works, we can put event into event store. After that, take it from our application, calculate state, put the state to different database. And after that, when we need to show the state to user, we can just show it from the database. It's called SQRS, and we will talk about it a little bit later. And now, the general benefit of this idea is we can use any kind of database as a cache. It can be really anything. And we can use different databases for cache because in some cases we can use relation database for searching and for index page when we need to return a lot of, at least with a lot of information. And for example, we can use the commentary into database for show a full page like a LinkedIn do with a page with your profile. So let's talk about the real world and where it can be useful. I found some examples of where it can be really useful. For example, it's e-commerce systems. In e-commerce, we have an order and checkout flow. And in this case, we need to remember what happened and what exactly we did with it because in this case, we can easily debug it or recalculate state for the previous time or something like this. Event sourcing is really popular in places where we work with money. And also it's most common example if you have, if you need to version control like Wikipedia docs, Google docs, group editing, event sourcing can be useful here too because you can travel back in time and recalculate the state every time. And also some domains contain event sourcing by default. For example, it's a tracking system or if you're talking about some stuff which show how games was done, we need to calculate when someone make a goal or something like this. We can use event sourcing for the systems too. And so if you're talking about Redux, we can say that event sourcing and event driving architecture is a little bit different thing. And Redux, you can start things that Redux is event sourcing but unfortunately it's event driving architecture because they use events in a different way. In event sourcing we store what happened in a system. In event driving architecture we event happened and everyone will be know about this. And in this case it's a little bit different way to work with it because event sourcing can be synchronous. Event driving architecture is synchronous by default. So yes, blockchain is a good example how event sourcing can work. And some pros and cons of all the stuff. The first one is easily to communicate with domain expert because you need to remember how business events work because usually in event sourcing we work with business events. We got logging out from Box. It's extremely critical for places which are related to money because we can audit what happened with some customer or something like this. We got time traveling and the most interesting stuff we can restore system state every time when we need it. And it means that for example we have two databases, one with events the second one, it's Postgres for searching or something like this. And when Postgres will down like in GitLab a few years ago or something like this we can just easily recalculate the stuff and state and just put it into a database. Event sourcing in general changed a little bit to a mindset because we don't need to work and think about tables. We work with changes and events in general. And in this case we can use any data structures which we want to use and easily change database implementation. For example we play it with Elasticsearch, understand that we need to use some relational models and move everything to my SQL database. And also event sourcing has a lot of cons. I found five slides of cons or something like this. And the most terrible cons is really complicated abstraction and it's not popular in Ruby. And in this case you need to explain it more and more and also developers need deep programming more. So it's really hard to get the state rises and crude if you try to build a block with event sourcing you will spend more than 15 minutes on this. And sometimes it's really hard to understand whole chain of events because you have a lot of different stuff in your system and it's not a current state. It's just a change and you need to understand what exactly happened. So also we have a problem with version and version compatibility because if we will change something we need to support different compatibility levels. It can be backwards or forward compatibility. And also we can't update or delete events. And if you live in Europe for example it can be hard for you because in Europe everyone can go for you and say please delete all information about me and you need to do something with it. So and I have some advanced topics to cover some questions. The first one is how to display created data as soon as possible and we have two different solutions for this. The first one is cheat user, how it works. We have a client web application and database with events. We don't want to use read and write models and when a user send the event to our web application we validate it and put it into database and on our client stuff we show the data like we have in a database. And the second one is web sockets and long pooling approach and it's a little bit more complicated. So the next question is my favorite question how to make write events order and why it's important, it's important because we have more than one application and one database and for example the first one tried to send an event, the second one tried to send an event and what exactly we will do with this situation we need to try to use some distributed logs, we need to introduce a lot of different stuff and I want to say hello to distributed systems and suggest this book again and also this talk with Roth Soferby from this year it was really good and this guy explained a lot of stuff around distributed logs and etc. So I made this talk in Europe and one of the question was how to delete user-related data because in Europe you can do it and we have two approaches, the first one is retroactivate event, you can read martin flower block about it and the second one is encrypt everything and lose data key. And also one more question was we have a list of events, how to search some information for example we have a list of events about users or something like this or maybe orders and we need to find some specific order by specific name or something like this and how we can do it and the most easiest way is QRS and write and read models and I'll explain what is it a little bit better on the end of my talk and let's talk about Ruby finally we have this abstraction and we want to implement something like this in Ruby and how we can do it, we have a simple way it's libraries, the first and I think the most popular library for this is Rails event store from Arkansas and folks from Poland the second one is a sequence they have a lot of stuff around this library and my favorite it's event to project because they have really a huge list of futures and a lot of different stuff also we can use BraveWay and build everything by self and for example if we want to use Kafka as event storage we can use Kafka it's a really good library built by magic and I really recommend this library if you work with Kafka and in the next version it will be much better or you can take pure Kafka adapter and build it by self or made it by SQL without any problems and I have some experimental repository you can see how it works in real life and if you know Japan language in Japan they have evento, it's mean events and in my case it's evento which means nothing and also I have zero tests for this library it's production ready library so let's try to explain how we can migrate from some existing part of code and for example we have action where user adds something to cart to our order and we have Hanami action with different stuff for example we need to validate our params after if cart exists if cart exists create copy if it doesn't exist create a new one after that send something into analytics and redirect our to order path and so the first step it's event storming event storming it's a really important technique to detect business events in a system a lot of folks make some workshops around how it works they use a lot of stickers and it looks really fancy and after event storming we can understand that we need to use two different events the first one it's item edit and the second one copy item edit and the next step we need to start apply our events or store it in an event store and for this we can use event store dot apply and put event with a full pilot into this event storage after validation so the next step how to make a business validation on business validation I mean this stuff because we need to validate that this item exists or not and we need to calculate state and for this we can use we can take a stream for specific order take a list of events and after that use project function with specific projection and it's look like this for example we have two different events and initial state and when we take one of this we put something into state or when we take other event we put something else into state after that we can calculate all events and ask do we have this item or not so and the next step it's subscribers it's subscribers it's something like a similar pop-up we can put everything and I'll start talking faster because I have only two minutes so and after that we can move logic into domain and that's all and we can use event sourcing only as a part of our system for example we don't need to store events based on user but we can store events based on order and what's the next the next is Sega who know what is it sorry but we'll talk about Saga Saga pattern what is it it's a long business transaction it's like a railway programming but more about distributed stuff and usually sometimes look like a state machine the next stuff it's my favorite part it's concrete responsibility segregation and some Martin flower here and how it works for example we have crude operation and in updating or deleting we put something into database with SQRS we have we are reading from we're reading from query database and when we need to update create or delete something we put everything to common side database and create events for updating query database I have 10 slides just quick so we have a right model you can find it here so let's the most important stuff is to look outside to Ruby because if you open an awesome project you will see nothing about Ruby I create something about event sourcing and DDDA again and so when I read this book the first time I look like this guy and it's really important because we are talking about business events in general and distributed systems and I can suggest this book this one, this one and conclusions I have fun so okay the most important part here it's this one it's really expensive and nobody know why they use it but sometimes when you understand that you want to solve this problem with events it will be better event sourcing crisis something else but it can break your startup or application after that you will be fired and so and I think event sourcing will be a trend in the future and if you don't trust me please trust Anjai it's a guy who made event sourcing Rails event sourcing gem and that's all finally big thank you to Anton