Pragmatic Event-Driven Microservices • Allard Buijze • GOTO 2018

[Music] good afternoon I was I was almost gonna say good morning but you know time flies when you're when you're having fun I want to start this this talk with a bit of an awkward moment for me I I need to make a confession and I need to confess the fact that I have built some horrible software in the past and on the other hand I'm pretty sure you did too and but I'm especially afraid of saying this because some of you might be maintaining my software and and in that case I I'm really sorry and yeah anyway so now that I got that off my chest let have a look at what that horrible software looks like and it might look familiar to you actually so I used to build software with this this nice domain mobile right we've we've learned that we need a domain model in our software and at least that was that's what I was taught and when you when you build a new system and I've worked a lot in Greenfield situations and some would say I was lucky some others would say are for you you didn't get to the real the real stuff but in the beginning the the services that you build map really nicely to to one of these concepts or entities in your model and then as you start developing further you notice that you know there's a second service and it really Maps nicely to another entity and and everything is nice and clean you know that feeling of that that clean application all that feeling you see little doesn't last longer than one or two Sprint's right it's it's about four weeks and then he'll starts kicking in and this one service comes in that's only needs to map to about everything that you have this this clean mapping and the whole architectural promises that you made in the beginning they just all fall apart and you end up with nice sequel and you know Java is easy sequels no no and this is an actual sequel query that somebody gave me and I hope you cannot read it because I promise you couldn't but then I started reading the sequel and I started reading the characters and even if you can read the characters you cannot read the sequel so I guess that's okay I guess that's within the boundaries of what I was allowed to do with this sequel statement but just to give you a summary there's 22 joins in six sub queries in here and this is normal unfortunately or fortunately it's has to say you don't see this kind of queries in every and every applications and I've built about sequel queries as well and building them is fine maintaining them it's a different story but we're done with the apologies so what do we do to fix those problems well these squares don't perform so we we solve all of our problems and we are tech guys so we add technology so we add caches all over the place we use session replication so we can have distributed sessions where we would distribute everything just because well one machine cannot handle everything anymore because that because of our sequel query we use method invocation caches because in with spring cache you just put an annotation on a method and then it's cached right so it's easy we can just do that why not we use worker pools because they think make stuff faster be careful if you make that assumption so we add caches all over the place and there's a when I was preparing this slide one thing struck me and I didn't really do that on purpose I was just exaggerating a bit with all the caches and I noticed that I put all my solutions to the problem on the left but the actual problem is in that domain model to the right the model is wrong and we're solving that by adding more technology to it so what we wanted to build was something really fast and and beautiful of course opinions may differ on whether this is beautiful or not but it's pretty fast compared to this but this is what we've really built right it's probably built with all the best intentions in the world and it has all the characteristics of the the car we saw earlier but for some reason and I have not tested this I am making assumptions that this will not outrun the other car but you know this is not software related this is cars and cars are different worlds fortunately there's also a a pattern for for the type of software that we're we're building or I say we that's a way of not saying I there's a pattern for the software I've built and it's called the big bowl of mud and here's some news for you it's not mud hence the term coat smell and all that everything comes together and in this case there's the there's an architect on top I was about to say me but and the architect is proud of its creation right this architect does not even notice the code smells in his creation it doesn't he's not aware of what he has built this is a bad architect and I hope it's not you don't recognize yourself in this and I I don't like making mistakes well actually I do like making mistakes I like making them once but this was a mistake I've made more than once right building an application every time you say next time I'm gonna think about my domain model slightly better and yet here we go again big ball of mud me on top of it array here we go so I started experimenting a bit with okay what do we need to do with this domain model and the way we experimented in in the time where I was abraham's boss is we we did things in public we put our experiments on github and then of course you have to give it a name and that name was not actual framework at the time it had a different name really crappy I will not say it and we started experimenting it and then I got a an email a couple of months later of a company said hey we're using your framework in production that was not my response to that remark I was more like oh and but there was two pieces of news in that one sentence first of all framework no it was an experiment that I should not use an experiment in production okay and the other one was it's in production by you know there's production and there's production there's all there's this excel sheet we normally used but now we need two people to update it so we've built this little application and deployed it on a Raspberry Pi that's sitting under the desk that we reset every day but I'm plugging the USB cable but no it was a medical system and it was used to track the tools used in surgery ouch unfortunately nobody died yet and the and from then on we started calling it a framework and we decided to give it a proper name and then that was really my sort of cue to say hey maybe I could use this myself in production so I started using it myself since then and the way it works and I'm not going too deep into into this but this is our this is my sort of history into into micro services or in my the road I've taken to to come to micro services and the way this the the we approach the the problem of the big domain model was by separating it and in this case we've separated creating different models for different purposes they nowadays it's called CQRS it has some different names in the in the past and basically what you say is well you create a model that is focused on handling commands if you were in the previous session with Alberto then command is a it's a trigger somebody does something somebody makes a decision to have the system do something and it might be triggered by clicking a button doesn't matter and you need to make decisions right what are the effects of this specific command what does the system need to do what and whatever it does it starts emitting events based on what what's happening because of that trigger and those events are then forwarded to what we call the projections and they are a model or they are models that focus on delivering information usually to users because they have a screen they need some information they probably wanted now because loaders are so 20:17 so we want to have this information readily available and easy to navigate through so we want models that focus on that so we can lose the difficult queries the the non performance queries and all the caches that we we try to put on it to solve the problems and on this road when we started and this started about nine years ago and we started noticing that you know monoliths are not really that bad and you might have heard this before I mean I'm not the inventor of the fact that monoliths aren't that bad but for one they don't smell usually unless they're in a park and there's a lot of dogs passing by they might start smelling but it's not the same as a big ball of mud right there's a big difference between a monolith in a big ball of mud it's possible to terror a monolith apart okay it's also possible to tear the big ball of mother parts but I don't think you'd that's a very nice job and there's notice of course there's a lot of observations from the in the community and Marti Fowler put it very nicely he said almost all of the successful stories that he's heard about micro-services have started with a monolith and almost all cases where they did not start with the monolith but just said hey here's a white piece of paper let's go for micro-services all the way those projects failed and I've been involved in some projects myself fortunately not as a not as the end responsible for them and I've seen some of those projects fail as well because it's incredibly hard to do micro-services there's a lot of things you need to to worry about and the question is really are you are you really up for it are you up to that maturity level in your organization and we're not talking about just just technology do you understand the technology to implement banker services but do you even know where to cut your to place your boundaries and this is actually a concept that came from Alberto over beer so be careful and he said you know what he says in practice is called noun driven design and it's a very simple technique and it is technique proven not to work but it's used a lot and it's easy you just take the specification of your system and every noun you encounter that's a service easy right unfortunately that's also what happens in practice so we have order service customer service product service inventory service etc and now instead of having created this big bowl of mud a monolithic big bowl of mud we have created a distributed big ball of mud hooray gone with the code smell well good luck if you're in that environment and the problem with these projects is not I mean a project failing is not a big problem but you want them to fail fast and fail cheap so within the management scope of that project you can try again right you've done an experiment that didn't really work out let's try something else out that does work okay we've lost a week who cares so what does a journey microservices journey look like and in our in our opinion and it all starts with and this is a Greenfield situation right so it all starts with a an idea some some concepts that's gonna make somebody rich usually that's what business cases are about maybe I should have put a little world a globe there with two hands like an idea that makes the world better but for some of us a better world is just filled pockets and what we know that migrating moving to micro services right away that's dangerous that is a very dangerous trip and there's a lot of pitfalls there's a chance of ending up like whatever that was when it used to be alive but there's also a big chance of you you just lose the way and and end up not really where you wanted to be where to end up so we want to take a different different route what we really would like to do and and this is what we've seen the the users of action framework do it's not something that we intended but it just seemed to happen is create a structured monolith make sure that within your monolith there are clear boundaries there are clearly defined components in that in that monolith that as the as time moves on and we discover some of the same non-functional Zoar we we hit a point where the monoliths cannot do it anymore we can start extracting these components and start deploying them separately because now we have actual reason to split a certain component out of of the monolith we have a reason to tear it apart and it might be because the let's say the deployments lifecycle of that blue component is different right we need to deploy that more often or maybe it's not a stable and it's generating these out of memory errors all the time so let's deploy it separately so we can let it crash without having the entire monolith crash because of because of it it might be because the team is just too large right you can only work with so many team people on the same repository so you might want to split because of that there's a lot of different reasons and they're all non-functional right and as time progresses we can extract more components and we end up in a place probably not in the place we intended to end up from from the beginning but we end up in a place where we have evolved into into micro services and of course I then there's a question do we really need to stop there what about server lists well that could be a next step maybe that we don't care how many instances of that purple component we have maybe just say here it is run it I don't care whoops and the the core concepts in being able to do this being able to transition between these from monolith 2 to micro-services is what we call location transparency and the concept of location transparency means that a component is not aware of the location and maybe even the existence of the other component that it interacts with it's about two components communicating and they don't care where they are so are they in the same in our case it says it's Java based but is it in the same JVM or is it on the same VM are they on the same host but in different VMs or and different data centers across the globe it doesn't matter the communication they have does not make any assumptions on that location and preferably a component doesn't even know it's speaking to that specific other components and it all starts with good API design and and nowadays event-driven micro services are implemented a lot to to overcome this right events are a very location transparent means of communication because the sender of an event doesn't really care who's picking that event up right so we see a lot of these event-driven microservices emerging and as it happens a lot in our industry we find a solution to a problem and then we start finding problems to match our solution so event-driven micro services tend to appear where they should not be but so just imagine an order service and there's another service that needs to know about ordered items and a marker services it's good that every component is isolated from the rest right don't use databases for integration I guess we've learned that lesson over the years so there's a line of communication between those and the order services publishing events not knowing that they end up in the other service of obviously but and it could be like oh there's order created there's item added the item removed in this order confirmed and obviously there's a lot of other events in the process it's not really that simple but none of these events will really tell that component on the right what items have been ordered because adding an item to an order doesn't make it an ordered item it's only an ordered item if it's added to an order which was then confirmed so that means they some of the logic on what it means what all these events mean has to be copied to the other side now the service on the right has to have intricate knowledge of the mathematics of what it means for an item to be ordered and again this is a really simple piece of math and it's fine to copy that but in practice it gets much more complicated and it's the type of coupling that's really annoying because it's implicit implicit coupling is the worst kind you can have because in the end you end up with a little ball but it gets worse this is not the worst case I've seen orchestration or coordination using events in in system that was impossible to comprehend and it's like Oh or the service says an order is created which was a trigger for shipping and it's really sent as an intent to trigger shipping in this in that case then the shipping service says I will confirm the inventory we confirm that we have their stuff that we can actually ship this and the order services ok I'm ready for payment now well that's again the type of communication where you're really pointing your finger at something right here you're using an event to tell the other components I am ready for you now you can do your stuff and it says ok orders paid our grades now I'm ready for shipping again we're pointing fingers so again there's a lot of dependencies growing between these these services and we're not really as transparent as we as we could be and that's because there's not really one reason to send a message to another component we've noticed that there's three reasons why a message would want to send our Soria why a component would want to send a message to another component and that's an event to notify that something happened it's a legitimate message I'm not saying events are bad but it's not all events there's also the command and that's a message that notifies that that notifies the system that a we expect a side effect we expect the system to be in a different state after processing this command than it was before right I want something done period and the other one is the query I have a need for information somebody give me this I need to make a decision somewhere or I need to show something to the to the user and I need information to show that show that user so an event is typically a it could be a data change right so I'm an order was confirmed something like that it could be a deadline like payment payment overdue or anything like that basically it's anything relevant in the domain and events storming the the session before me is is a very interesting technique to to uncover these events in in an organization and the events typically follow a publish/subscribe mechanism right we are very aware of this i I assume so a component just publishes the the events and any component that wants to know about that event can pick it up right that's easy but it does get a bit more complex what if you have two instances of a component and only one of them needs to know about that event what if they're updating some table in a in a interview model or in a in a database it doesn't matter and there's just two of two instances that can do that you want an event to be unhandled only once in that case you can use exclusive consumers which basically means the the top instance here will get all the events and the other one will just wait for his sibling to be killed and then you can take take the word work and if that other one comes back he's in waiting mode oh this is a beautiful waste of resources not so much of CPU because we have good technology to where to share that but probably that thing is trying to make a connection all the time it's consuming memory so this is not really efficient in practice what we see most is competing consumers that means that both of them are just reading messages off the same queue and every message will be delivered to whoever takes it off first that's very easy at least to to implement but again there's a little problem here in the sense that what about ordering of messages now you cannot guarantee that the item added is handled before the order created so you might be adding items to an order that hasn't been process of the creation hasn't been processed yet now a message ordering is a completely different topic we can have a different session about that but wouldn't it be nice if you know that events are emitted in a certain order that you can also consume them in that same order so there's a different way is there to use balance consumers use some hashing algorithm to decide okay if if modulo 2 ends up with 0 its you if it's 1 it's you of course that's of the worst hashing algorithm out there but just for the sake of explanation so if two events are are about the same order they will end up in the same components now that component doesn't need to worry about event ordering anymore it knows that all the events of a specific order and sorry for overloading that term all the events of the same order are handled in the order they were created so let's move to command so commands are a request a side effect kind of message right we want the world of the application to be different after the command that was before so it could be change this state or usually they're a bit more explicit why you want to change the states or maybe send an email I want an email to be sent right and something happens which is the email was sent commands typically have a single destination there's one component somewhere in our micro-services landscape or our component landscape so to say and there's one destination for it and there's one component that will will handle that and typically a commands do not have big replies they just have an OK type reply sometimes there's a little bit of data if there's an altar generator or a generated value somewhere you might want to to return that value but usually there's not a lot of information because it's not the reply that we care about now come on routing could be done round-robin right a typical load balancer would do that every requests you get it will just go any meenie miney moe to the next one but that again might be very inefficient we've we've seen it during the keynotes you can use consistent hashing to route commands for the same concept to the same machine so you can use local caches and not caches as we saw earlier to solve big performance problems but caches the way they were meant to be as an optimization of a system that works well without them right so again here we could use consistent hashing and with commands commands typically target something like an order so in that command if you target an order probably you mentioned the order ID somewhere as well that order ID is beautiful input for this hashing algorithm so different commands that mention the same order IDs should be routed to the same machine as long as that machine is alive and when that machine dies we just route it to whatever remains right and the last one is I want to know something that is query I need to have information and unlike the other messages this is a message where the value is not on the message being sent but the value is in the message you get as a reply and in practice we see this implemented use using HTTP usually get all the time but that's only one one of the the patterns that we've we've seen and that's a point-to-point query right it's just pointed someone and say hey you give me give me the answer to this question and that works really well when you have a question that has a single true answer right and in this example what is the price of a certain products well if that price is 49 then great that price is 49 but if you're in retail you'll probably know that there's no such thing as the actual price pricing may depend on things if you if you go to the Albert Heijn which is a large supermarket here you can get a bonus card right and if you have that bonus card you can get discounts so there's the same product and different people will pay different price for that product so there's no true answer what does that product cost well it depends are you do you have a bonus card right in other words did you give away your privacy to that other company and obviously you get money back for it right you can sell your privacy that's fine so in this case what we will want to do is it's got together query right we have a question and we let any component that has an answer for us provide an answer and we have to be a bit careful here because we need some timeouts because we don't even know if there's components providing us with an answer right so the top one could answer just the the default list price right 199 let's assume it's a different product than the previous one and if you are a bonus cardholder their price is 149 that's great and if that component goes down it might happen it will just not reply and then unfortunately bonus card holders will pay the regular price that will definitely piss them off but maybe they don't notice but something nicer that we can do is we can change the behavior of the system without changing any of the components in the system we can put a component here that says well if whatever condition if they're if it's sunny outside ice creams are $0.99 I'll usually sales way around to get more expensive but and then if we don't care about that anymore we can take it away so we can change the behavior of the entire system without touching anything in the system and that's very powerful and of course with power comes great responsibility you can also destroy a system like that you know don't touch anything and still it breaks and there's another one that we've seen in in use and that's a subscription query and that's the kind of query where you say keep me up to date on the price of for example in this case so the result is actually the initial price that you get and then all the deltas in whatever shape or form that they come so in our case in our example the price could be 49 but as it drops to 39 you send the Delta of minus 10 the Delta may also be the new price that's really up to you to you to to decide in every specific case and this is a very powerful way to keep components up-to-date on something that they want to be kept up-to-date on so you don't have to do polling you don't have to replicate the logic of okay how do we keep this price up-to-date how do we what kind of events do we need to listen to that that can update this price or you say now as well give me a model and send me the deltas of a certain model as it changes and we've we've implemented scenarios like this where the model was alive on the on the client side usually in a browser you just have a model there and as data or as the model on the server changes you send those deltas over and now you have a real-time UI which is scary for a lot of users now still nowadays they are used to pressing refresh to get new information still so now if we look at these event driven micro services and look at these different types of messages that we have we can take away that duplication of logic we can now wait for in order to be confirmed and say okay give me the details then and now I'm getting information about the items that were ordered right we know that this order since it has been confirmed everything in there it's ordered and we can get the details of all the items and we're not duplicating logic anymore we still have an event to trigger so we don't have to do polling like Oh what what the orders do you have give me the total list of orders place in the last 24 hours and then do a delta with what you already knew I'm pretty sure some of you have built integrations like that we include it and it's horrible I don't like it and there's another thing about events events they they retain value like commands are nice they trigger a side effect and then really the value of those commands is gone a query you get your information and really the value of that query is gone but the fact that something happened at a specific time is very valuable at any moment in the future right there's a lot of value in those events they they represent something that happened in our in our domain right an event sourcing is is a pattern that's being spoken about a lot these days it's it's implemented a lot less for for some obvious and some more or less obvious reasons and what you really need to to store events is an event store obviously right what else would you call it and an event store is a mechanism that allows you to not only store the events but also retrieve them in specific ways so with event sourcing if there's a component sending out these events these events have value to that component omitting it as well right we can feed those events back to the order service and now the only thing the order service has in terms of state is the events that they emitted in the past because those events basically tell everything that happened and theoretically unfortunately also in practice you can use those events to reconstruct state of an order instead of storing the current state of an order you just rebuild the current state of an order using all the events that were emitted about that order in the past and that gives us a very powerful audit trail right because those events represent the facts that happened they're facts and now we're not only publishing those facts as a side effect of an operation but they are also the source of the decisions that we make and that's a very important concept in event sourcing and unfortunately in some of the explanations of event sourcing that's lacking the fact that you know they say it's the single source of truth and suddenly you notice that in the description they still have two sources and they're basing the truth on something that is not the truth so how true is the truth if you don't base it on the truth so the operations that you need to know that an events or needs to be able to do are upend write only new things can happen unfortunately humans still live in the now we don't have a way of traveling while you can make your now go slower than other people's now's but that's about all we can do in terms of time travel as far as I'm aware of and the other thing is we need to be able to validate this sequence like we want to be sure that we are not allowing two conflicting events to be appended right and that doesn't mean everything is full sequentially you can only have one thread publishing events there's there's other ways but will will not go into too much detail now another operation that we need to be able to do is a full sequential read so that service on the right that is interested in in in in processing these events heed it can track this event stream basically right it can fetch the first event and then when that's done it fetches the next one and the next one and then keep them can keep a pointer on where it left off right some of you will probably now think hey Kafka right yes Kafka is really good at doing this but here's the challenge now we need to do this as well and this is where were Kafka abandons us unfortunately so read the events that were emitted by a specific aggregates like without going all the way through the entire stream right so you want to read those specific events that were emitted to represent changes in a specific order or their meaning the thing you bought right in that order not the sequence so those are only a few of the the events in the entire stream other stuff is happening as well there's others other orders are being dealt with and there's other things beyond orders that are happening as well and we need to be able to read those efficiently to reconstruct the current state of an order so we can make decisions again based on the facts that we have emitted in the past so with those with those messages what I what I notice is for whatever reason we tend to forget the fact that first we need to look at what our requirements and then choose technology and I fell into that trap a lot as well you say okay HCP is here everybody uses HP so why should I not news HTTP for everything right so let's do a query using HTTP GET well who says that's the best way to do it right you need this consistent routing well let's create a URL pattern then that has a specific value somewhere so we count the number of slashes and we'll tell the load balancer to routes whatever values in between those slashes and if that's the same rather to the same machine well you can probably do that but is that really the kind of work that brings most value to your to your customer or to the business that you're running there's a lot of beautiful technologies to get information from A to B and they all have different they've made different choices so we should really take a step back every now and then I think okay what what is the message I'm trying to get across and then choose the technology that matches that routing pattern now this is only easy and nice and if you're in a controlled laboratory environment this will work why the computer under your desk will be happily serving you all the commands queries and and events but at scale things are different so you could wonder how how do you when you have this massive scale system how do you get all these events routed correctly to all these other components and how do you get this command to exactly that component that can actually handle this in this huge deployment of systems how do you scale this well fortunately the answer is really simple you don't this this concept like this does not scale fortunately there there is a an actual solution for this we'll get to that in a second apparently the what you get is an unmanageable mess of systems communicating to each other right so there's this shipping module that wants to know an order is placed right because it needs to ship that stuff that's great but in the silo called order management they go like oh well it's not that simple it's not just like an order was placed right there's stuff happening it's really complex don't worry you don't understand but so they talked about an order cruise created items were added I just removed shipping addresses for added billing addresses Lola and then maybe after a while they finally confirmed the order right and there's a there's a language mismatch here and again just like the example earlier we're going to copy knowledge or logic of the mathematics in this case of what does it mean for in order to replace and what is the kind of information that we need and they need to learn each other's language to be able to do this fortunately the solution is in domain-driven design they define this concept called bounded context and a bounded context is really a language barrier is within a bounded context people speak the same language they they use words that have specific meaning and those words might also be used in other contexts but it has a slightly different meaning right and we want to be very careful about transitioning this boundary so within a context is it's safe to share information is safe to share all these events that you're producing and it's safe to consume events that were that are speaking the language you understand right but as soon as you cross that boundary you want to be more conscious about what kind of events you emit right what kind of information do you want to include and typically the events across these boundaries are the events we call milestone events they represent something slightly more important than anything else that happens right and especially if you use event sourcing everything is in events every little change no matter how small is an event and you do not want others other components to be tightly coupled to those nitty gritty details so we want to be more conscious about those those events and in some cases that might mean they are very coarse-grained not as frequent event containing a lot of hey an order was placed here's some information that we are going to or here's all the information of the order and you get these fad events right so let's go see that example and there might be there might be a component there in the middle of the boundary saying okay if all this happened I'm going to use that information to publish publish this massive event but of course events were not the only building blocks so we can also use an event as a trigger and then do a query and send that information out another approach would be to have very small events just say hey this ID this order ID represents an order that was just confirmed if you want to know anything query it right because maybe the sender doesn't know what kind of information the ian's are really interested in both have their pros and cons right basically in a small-scale event is a request for DDoS right you send out this event hey this order changed now every component that receives that events will start querying your your models for information so it's basically a DDoS me with a was a bunch of queries now sometimes I got the question or quite often I got the question okay you started off with this axon framework and now you started talking about messaging and etc where does this axon framework thing fits in this large-scale micro-services story and basically it since axon framework is more of an implementation framework it's it's Java based apache license so you can freely grab a copy and start playing with it it works well I said within a certain bounded context within the applications inside within the components inside and it gives you a Java based API towards an event bus query bus and command bus which gives you the location transparency abstraction that you need to be able to scale this system if if the necessity comes comes by and it's very important that the business logic and the infrastructure logic are separated because the infrastructure logic depends on your noun functionals right if you're non-functional change you do not want to change any of the business logic code that you've written right so having that separation is very important so within the my within let's say deployable units you would have a axon framework as a framework to handle the communication for you and it communicates between components within that same VM but of course we might have extracted some of those components to different VMs and now we need a way to get that communication across and there's a lot of hooks and api's through a lot of libraries some of them open source some of not that you can use to to get messages across from one VM to another and obviously we've we've we've built some of those ourselves as well and the way that works is we routing based on what we call just enough intelligence and we know that we all know about es B's right are there any members of the ESP fan club in here oh that's it surprise one he raises his hand like this but these bees are very smart systems right they know they understand the messages that your you're sending and in in a lot of cases I will not say all apparently in a lot of cases this means that there's a lot of logic also implemented in this ESB and then the ESB Department as a lot of these installations end up with they they've got control on everything so every project has to wait for these B guys to implement something that does not work well in in certain environments so what do we do we go to the opposite we go to typical message brokers like the JMS or AMQP based brokers and they are somewhat Dumber when it comes to the meaning of messages they're just pops up systems and they're byte arrays in and byte arrays outs and there might be a little bit of routing but we think the the sweet spot is in just understanding whether it's a command the query our RA or an event because they have different routing patterns and if you know that oh I've got a query I just need to route it to a component that has said it can handle that query we can do very smart routing based on just that little information of what type of message is it and now the sender doesn't need to know where a certain component is which component is responsible for dealing with this specific request we don't need we don't need to know a service name or or worse a URL of a specific service that we need to invoke basically that's what we are about and this this whole talk is more or less our our experience in what pragmatic event-driven micro services look like I I hope that you have some takeaways from from this talk thank you any questions hey think if we're to talk a question about the event sourcing part how do you handle gdpr and people say I want my data delete it and it's in the event yes so that's an interesting question gdpr is still fresh in our minds right we we've passed a deadline but if we didn't get rid of the problem just quite yet there's there's two different solutions that we see first of all is do not include any GDP are related so personal information in your event store that's easier said than done because usually also that information is very important to have events or an approach that we take personally is crypto thrashing so basically you encrypt all the information that falls under gdpr and that's usually slightly more than you anticipate you encrypt that information in such a way that even when two values are the same and they're encrypted you have different encrypted encryption results right that's important otherwise you just have certainly musician and you probably still get a fine and but you encrypt that information with a key that is specific to the the subjects that you're encrypting information of so if that subject says please forget about me you just say okay here's your key it's gone and now that information is useless right and it will if encrypted properly it will remain useless for so long that entire humanity will might know anyway so that's that's some ways we we handled TV PR and we were doing that since slightly more than a couple of weeks now any other questions then that is it thank you very much alert you

Channel: GOTO Conferences

Views: 34,870

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, GOTOams, GOTO Amsterdam, Allard Buijze, Axon Framework, AxonIQ, Microservices, DDD, Events, CQRS, command query responsibility segregation, domain-driven design

Id: vSd_0zGxsIU

Length: 48min 25sec (2905 seconds)

Published: Tue Sep 04 2018