Not Just Events: Developing Asynchronous Microservices • Chris Richardson • GOTO 2019

[Music] so this is my talk on on developing asynchronous micro services and sort of the motivation for the talk is really you know today we hear a lot about event-driven micro-services and an in reality the the patterns of communication between micro services are a little more general than that and so in this talk I'm gonna describe how to use asynchronous messaging which includes events but also includes asynchronous request response to implement transactions and queries in a micro service architecture and along the way I'm going to talk about well micro services are more than rest you know it's another common sort of anti pad and in a sense anti power micro services are more than just events and also micro services are not equivalent to just event sourcing because I often I see event sourcing and micro services get mixed up together and I might also mention that Kafka is not an event store despite claims to the contrary so before I get going a little bit about me so I've been programming for a very long time in fact my first paid job was actually back in 1982 so kind of a while ago first significant job was implementing Lisp systems I also at lea ended up programming in Java and 13 years ago my book pojos in action came out which was all about spring and hibernate which are great they're still going strong back in 2007 started tinkering around with this obscure API from an online book store namely AWS ec2 created the original Cloud Foundry and then that back in o 9 got acquired by spring sauce which then got acquired by VMware spent part of you know four and a half years that spring source VMware and then pivotal and then pretty much for the past five and a half years I've been folk just on the micro service architecture traveling around the world helping clients adopt the micro certain adopt micro services also have a start up building a platform to simplify the development of transactional business applications using a lot of the concepts that I'm going to cover today and the s my book micro services patterns came out back in November and if you want to get a 40% discount of it then just follow that link go to CH go 2019 - micro services and also have the website micro services dot IO I have that link at the end as well so yeah if you there's a pattern language their articles code and also a platform that lets you assess your vert your micro service architecture and identify areas to improve so that's me let's get started we're talking about micro services so I first want to begin by describing one of the key challenges that you will face when using the micro service architecture and it's in the area of transaction management and querying and then I'm going to describe the solutions to those problems which all involve some form of inter in asynchronous messaging between the services so let's look at the problem so if we look at the definition of them of the micro service architecture so it's an architectural style that structures an application as a set of loosely coupled services you're basically applying functional decomposition to break apart what would otherwise be a large complex monolith if we look at an individual service you know it's an independently deployable component you know and today that typically means it gets packaged as a docker container but that's merely one possible way of deploying your services the key part of a service is its API and that that's its reason for existing is to provide an API to its clients the API consists of two parts there are operations things that can be invoked and there are two types of operations there are commands which mutate data so if this was the order service you could place orders revise orders cancel orders there are also queries which retrieve data find orders find order history and so on there's a couple of different ways of invoking operations you can use something like rest or G RPC synchronous protocols but as you're going to see in this talk it's quite common to use asynchronous messaging in fact perhaps you might use synchronous communication to talk to clients of the of the system but internally a lot of the interactions between the services is done using asynchronous messaging the other key part of a service API are the events that the service emit so if this was the order service it were typically amid events like order created order revised order cancelled and so on and then services can invoke the operations of other services and they can also subscribe to the event of those other services as well so we've got this sort of rich patterns of collaboration between between these services oh yes and the service has its own database its own private data which as I'm going to explain in a minute is actually the source of a lot of these challenges and the reason we're doing this the reason we have we want to pursue the micro service architecture is basically to enable DevOps which includes continuous delivery and continuous deployment the rapid frequent reliable delivery of software and the micro service architecture enables that in two ways it enables it directly by giving you the testability and deploy ability that you need in order to do continuous delivery and deployment it also enables you to have loosely coupled autonomous teams the so-called to pizza teams that are highly productive so that that's sort of the micro service architecture and the motivations for it so if we now look at like a really simple example so imagine that you're building an online store and I'm sort of ignoring the the sort of kind of front-end stuff so just imagine that in your honour in your online store there's a REST API somewhere that lets you create customers create orders and then find orders for a customer and find recent customers so that's sort of the general idea now if we broke that apart into a micro service architecture you might have a customer service that's responsible for customer management and you'd also have an order service that's responsible for managing orders so simple decomposition each one of those services has its own database so the customer service has its own customer database which might by the way just be a schema on a shared database server that's more of a capacity planning issue the order service will also have the order database you know it seems fairly simple sitting in front of them you might have an API gateway that exposes the public API and then is responsible for routing requests to the appropriate service so for instance if there's a request to create a customer that's going to get routed to the customer service likewise if there's a request to create an order that will get routed to the order service seems all kind of simple and straightforward but if you dig into this a little further one of the key requirements is that customers have a credit limit and so what that means is in order for the order service to create an order it actually has to go and interact with the customer service so something that appears on the surface to just be you know localized to the to the order service actually spans both services and requires basically a transaction of some form and likewise if you look at the queries there they're actually doing the equivalent they need to do the equivalent of joins between these multiple service databases and that's challenging so you know if we go back and we look at transaction management in a monolithic application you could enforce the credit limit with some simple sequel like this right you begin the transaction you know find the existing orders find the event find the credit calculate the available credit if it's sufficient insert an order commit the transaction and then the acid properties of database transactions means that even if there were simultaneous attempts to create orders for the same customer this business rule would be enforced but in a microservice architecture this is a challenge orders are in one server orders are in one database customers are in another or to be more precise they're actually private to the respective services so you can't straightforwardly implement database transactions that look like this and if you did you need some form of distributed transaction two-phase commit or XA which for a whole bunch of reasons is kind of fallen out of fashion and is not practical in many modern systems likewise querying is no longer straightforward in a monolithic system it just be trivial to do a join between the customer and order table to find the customer in their orders once again customer table is private to the customer service the order table is private to the order service can't do something like this so yes so as you can see transaction management and querying is sort of no longer straightforward in a micro service architecture at least as far as transaction or when chased and say when transactions or queries need to span services so I'm going to talk about transaction management first and then later on talk about querying so the solution to transaction management in a micro service architecture is to use the saga patent this is not a new idea it came from a paper back in 1987 and sort of as the name suggests it's sort of this notion of long-running kind of sort of transaction in a sense basic idea with sagas is instead of a distributed transaction spanning multiple services you break up the transaction into a series of local transactions in each one of the participating services so it has some local transaction happens in service a then it happens in B and then it happens in C so that's the basic idea if we look at the order the Creator the saga for creating an order it would work something like this you know the order service gets the request that initiates the saga the first step of the saga creates the order and actually creates it in a pending state which indicates that it is in the process of being created so actually known as a semantic lock which I don't have time to talk about more but it's a really key key issue with saga design the order that once that transaction has is executed that cut the the reserve credit transaction occurs in the customer service and then assuming that the customers credit can be successfully reserved the order is approved so it's a transact so we've instead of one global transaction it's three local transactions to in the order service one in the customer service and so that's sort of the basic idea you have to break things down into this series of steps it actually creates several problems that I don't have time to go into in a lot of details and just in this talk it's just focusing on the high level aspects but number one one challenge is sagas as you're gonna see are asynchronous yeah they might be initiated by a synchronous opera request such as an HTTP POST so you then have the challenge as to when to send back the response another challenge is implementing row backs right you know like in an acid transaction traditional database transaction you can execute a rollback statement that just undoes essentially all of the updates that you've made so far the challenge that you have in a saga is that if say the fifth step of the saga fails the first four steps have actually already committed their changes to each of their local databases so you actually have to explicitly undo those changes which is sort of an interesting little challenge and then also sagas a not acid they actually are a CD they lack the isolation property of what you have some sort of regular database transactions that means that the ex the execution of saga steps can be in of one saga steps can be interleaved with the execution of other of steps of other sagas that opens up the possibility of database anomalies such as lost updates and fuzzy reads if anyone can remember sort of database theory from from college so you actually have to use water known as countermeasures such as the semantic lock like the the state of the order is pending until it has been approved or rejected and I've got a whole other talk about that that goes into this in a lot more detail but here I'm just going to focus on sort of the asynchronous aspects of Sagas so not so that's the basic idea with sagas sequence of steps so next question is how do the Saga participants communicate so you might think that you could use rest but there's a number of challenges with rest so any form of synchronous communication introduces temporal coupling the client making the request and the service have to be up simultaneously for that request response cycle to complete effective to complete successfully so that that immediately reduces the availability of system and then there's sort of really interesting failure scenarios so imagine the order service makes a rest request to the customer service which is temporarily unavailable it could keep retrying assuming it you know it has time within its deadline to keep keep retrying and you can make that work right but then let's imagine that the order service makes a request to the customer service and then fails right so the customer service is going to reserve credit but the order service is not able to receive that response and so your system is in this potentially inconsistent state you could rely on whoever is invoking the order service to keep retrying but that might just be a user you know who walks away and closes their browser so it's really challenging to to implement sagas using synchronous communication in a way that guarantees that the saga will run to completion so for that reason it makes a lot more sense for sagas to be implemented using asynchronous messaging so the participants communicate through a message broker that gives you at least once guaranteed delivery because if you have those properties it means that even if a sug a participant is temporarily unavailable the message broker is going to keep retrying the delivery of that message until it's processed so that that will guarantee that the saga will eventually run to completion so think of these saga participants as ex as exchanging messages through some kind of message broker you also need other properties of the message broker in order for this to work namely the message broker has to have ordered delivery messages need to be received in the order in which they were said otherwise things could get really confusing like an order canceled mess event arriving before an ordered created event for example and there's also a the technical requirement around you need a message broker that lets you scale out consumers while preserving ordering some message brokers have that built in like Apache Kafka consumer groups and ActiveMQ other ones don't but that's sort of a whole other technical detail so now if you think about a step of a saga it's basically consists of this pattern repeated over and over again so the service execute the transaction that updates its database and then it will also send a message or publish an event which will then trigger the next participant in the saga to execute its local transaction and there's an interesting sort of sub problem here about how to make those two things atomic how to atomically update the database and and send a message friar the message broker and I'm going to get back to that at the end of the talk so then the next question is how to kind of coordinate the transactions or how to coordinate the saga because after after each step of the saga execute some logic has to run to decide what to do next and if there's success which direction to go if there's failure which direction to go so you need some logic somewhere to decide to kind of coordinate this and there's two different patterns for doing this one is choreography which is where the decision-making is distributed amongst the participants in the system or you can have orchestration where it's centralized in one place there's literally as you're gonna see there is literally a class called create order saga that defines the steps of the saga if we look at what choreography it's actually event based and it's actually a very common pattern which I think has led to why people think of Micra services as being event driven and it works like this so a request comes in to create the order the order service creates the order and it publishes an order created event and that event goes to the order events Channel the consumer service subscribes to that channel receives the event was and then attempts to reserve credit it then publishes an event indicating the outcome which is either the credit has been reserved or the credit limit has been exceeded that goes to the customer events channel and I should say channels are an abstraction over whatever the message broker provides I know we all want to use Kafka but really in reality that's not the only option but think when you see channel think Kafka topic JMS message queue or total JMS topic and and so on it all depends on what message broker you using the order service then gets that event and then either approves or rejected or rejects the order so with this pattern the participants are just exchanging messages each one is saying I've done this and the other one goes oh okay I'll go and do my part and then it announces what it's done and that that's basically the pattern with choreography and it's actually quite sort of natural and intuitive in many ways and when I first started building micro services I was doing this even though I didn't know what it was I was doing it took like a year couple hits before I figured out that these this pattern that I was using was known as choreography based sagas so you know they're very sort of various benefits and drawbacks of choreography one is it's kind of simple especially if you're using event sourcing in fact I was using event sourcing and it was just like yeah everyone's omitting events and people is subscribing and and there was only later that I realized that that was a specific instance of how to do choreography and as you're gonna see choreography is not the only way and since everyone is communicating through events there they're fairly loosely coupled at least in a sort of temporal run time sense right they're not there's no synchronous communication the drawbacks however to choreography are really interesting so one is the implementation is decentralized if you want to understand how a given sagar is implemented you have to go look at the source code for a whole bunch of services because some of them are publishing events other others are subscribing to the events there's no one place in your code that describes that saga there's also cyclic dependencies they're listening to one another at one another's events an input which in itself is potentially a challenge but in this example the customer service has to know about all of the order events that could affect the credit and that's kind of strange because the customer service should be an expert on customers right it shouldn't have to have detailed knowledge of all of the things that you know it shouldn't have deep need to have detailed knowledge of orders that's the responsibility of the order service and then sometimes when you're using this pad and you just want to tell one of the services to go do something whereas with this pattern you can only sort of say what you have done which is it's like a very passive-aggressive way of communicating in a sense which as you know can lead to can lead to problems so the other option you can use is orchestration which works quite differently with orchestration there is a centralized coordinator or Orchestrator that is telling the participants what to do it's actually invoking them but not with rest or some synchronous protocol it's using asynchronous request response it's sending a command message to a participant saying do this and then the participant is sending back a response message but at the heart of it is a saga Orchestrator which I end up abbreviating to just saga that's a persistent object so it lives in the database of the of whatever service is owns that saga and it implements a state machine and it invokes participants and the basic way it works is pretty straightforward when a saga is created it figures out which participant to first send a request to sends it a command message then it just gets saved in the database where where it waits until a reply comes back and then when a reply comes back it gets loaded from the database handed the reply message that triggers a transition of the state machine and it figures out what participants invoke next invokes it and then it gets saved back into the database and it just keeps going around this reply processing loop until the saga has run to completion so it's sort of kind of like a workflow and I know some people are sort of using workflow engines for this kind of thing though I would argue that the come this is like such a race the SOG is a very very short-lived you know unlike a business process that's you know that worked which is lasting hours minutes days sagas should last tens of milliseconds right so it's sort of like a distributed transaction just done done with asynchronous messaging so if you're using what's at BPM to describe your SOG as you're probably doing it wrong they should not be that complicated so the way the way the orchestration based version of saga should work is like this where the order service gets invoked it creates the create order saga that persistent object that implements the state machine which lives in the database that immediately turns around and creates the order is that sort of step number one and then it sends a command message to a customer command channel telling requesting the customer service to reserve credit so it's not an if so even though they're communicating via a message broker the pattern of communication is radically different it's request reply not sort of pub/sub event so it's sending a request to do something the customer service processes that sends back a reply message which is received by the create order saga which will then assuming it's successful approve the order so yeah if you didn't look too closely you'd see message channels and messages going back and forth but once again the the meaning of those messages is very very different its request reply as opposed to domain events which is like I've done this so there's a bunch of benefits to this and I should say that there's links at the bottom of the slides where you can go look at the code that implements this I realize this shortened version of the talk I actually don't have code in the slides but I've implemented customers and orders at least two different ways possibly three with choreography orchestration and I think there's also an event sourcing version as well but the benefits of orchestration is that the definition of the saga is centralized in one place in the example code there is a class called create order saga which lists the steps another benefit of this pattern is that it reduces the coupling the customer service is focused in this in this example on customers it knows nothing about events and of the that are emitted by the order service and instead it simply has an API for managing the available credit reserve credit release credit and so it also gets rid of cyclic dependencies at least in this example the one drawback if any where it requires a little bit more complex requires some kind of SOG orchestration framework but coincidentally I've written an open source one called eventuates so that's not a problem is that there's a risk that you put all of this business logic you you start putting business logic into the saga class and you end up having sort of dumb services that are just sort of performing crud and you want to just don't do that right just push the business logic down into the services where it where it belongs so that's like a super quick sort of whirlwind tour of transaction management you know as you can see it it's you use sagas sagas can either use events or asynchronous request response to communicate and there's a lot more depth there I mean in particular around the designing compensating transactions that's a challenge and also using countermeasures to deal with the lack of isolation between sagas is is another challenge and yeah I'd refer you to I should say go read my book but also the other presentation so the next thing I want to talk about is queries right specifically queries that retrieve data that is scattered across multiple services so with this simple example you know if you want to find the orders for a customer you kind of have to go to the customer service to get some information about the customer service you have to go to the order service to get those orders now one way to do that is to employ the one way you can implement this query is with API composition which is where the you have an API composer which in this example is the API gateway just simply turns around and invokes the respective services and just get gathers the data and in a lot of cases it works quite well and in fact it's the preferred pattern for implementing queries in a micro service architecture the problem is is that you can very easily run into scenario you can have queries that cannot efficiently be implemented using API composition so here's an example where we want to find all customers who have recently been created that have placed orders over a certain amount like high dollar value orders that have shipped so it's doing a join between these two services trivial in a MOT in a monolithic architecture but it's an example of a query that is not that efficiently implemented in a micro service architecture so like one way of doing it for example is you find the recent customers by querying the customer service that gets you gets you a list of customers and then you then the API composer could iterate through that list of customers getting their respective orders so that's sort of a one plus an execution strategy where you've got lots of round trips which is likely to be inefficient the other strategy is you find the recent customers you find the recent orders that have been shipped so you two queries to each of the services and then you basically do an in-memory join but that's to potentially large data sets and you're sort of going down this slippery slope of basically building a distributed query engine and even if you could come up with a good way of implementing this particular example there are many others where it just sort of doesn't work efficiently and so for that reason you want to use this other pattern known as CQRS command or a command query responsibility segregation which is a really complicated way just simply saying maintain a replica of your data in a format that can be efficiently queried so in this example there's a customer order of you service that implements fiying customers and orders and it's got its own database a replica of the data in a format that is best suited for that query and that replica is kept up to date by subscribing to the event that are being emitted by the services that own the data in this example the customer service and the order service and you know this is a good fit for no sequel databases it's mutable up there I can barely read it here so for instance you could use something like MongoDB which is really good for storing blobs of JSON right so you know you can imagine a design where for each customer there is a MongoDB document that stores information about the customer and and that's kept up to date by subscribing to customer events and then you it stores information about the customers orders as well which is kept up to date by subscribing to the order events and the neat thing about this is one primary key based lookup and you get back all of this information about the customer and their orders and you can do something similar with Redis or just pick your favorite no sequel database and the origin of the term comes from the fact that in a traditional system you have the sit one data model is used for commands and for queries the idea with this is you segregate the data models and you got a command side data model and a query side data model and the query side data model is kept up to date by subscribing to events and in a real world system you might end up with multiple query side data models each one is optimized for a particular query or set of queries and you could also choose the database that's the best fit so if you're storing blobs of JSON MongoDB or if you're doing text searches maybe it's elasticsearch or if you are you doing graph searches it's neo4j so you so not only are you designing the schema that's the best fit for the queries it's you're you're also picking the database that's the best fit as well though there is you know that concept of like multimodal databases so it gets all a little blurry because there for instance like with Redis there are add-ons to Redis that can do text searches and graph searches and and so you might just have one one type of database implementing all of these different views you know one thing to note about these views is that they are disposable they are replicas so if you need to change the schema of one of them you can just throw them away and throw it away and rebuild it from scratch one challenge with this architecture though is that there is a replication lag between updating the command side right issuing the I don't know creating an order or revising an order and and when the query side is updated because an event gets published then goes through the message broker and then the view gets updated so maybe there's like a 20 millisecond lag between the two but that's forever in computer terms and so you could imagine a client issuing an update request and then immediately turning around and doing a query and it might get back the old version of the data no different than updating the my sequel master and then querying the my sequel slave and not seeing what you just wrote see you have if you're designing say the UI for sure you have to take this into account you know in the comment Rick say in an angular application or a react application as you update the browser side data model after you know that the command has executed successfully and skip of querying issuing a query to the server with the idea that eventually when the user sort of navigates away and triggers the query the the the query databases has been updated so there are solutions to that so that's CQRS really really useful in a micro service architecture although it obviously does add complexity because you've got replicas and you potentially have polygon persistence as well so the next thing i want to talk about is sort of kind of the tet it's sort of a technical foundation with some of this know and which goes by the name of transactional messaging if you remember I said each step of a saga needs to update the database and then publish and publish an event or send a message and the challenge is how to do those two things atomically we can't use two-phase commit because that's sort of a tech like JTA with JMS and JDBC because that's the kind of technology we're trying to avoid by using sagas in the first place right so some folks say well just publish to the publish to the message broker first and then have a message consumer that updates the database that that gives you a guarantee of atomicity but it doesn't work with a whole bunch of scenarios because the service can't read its own writes basically the you know it reads and then eventually the database gets updated but there are many scenarios where you need to be out of read and write as part of an asset transaction locally so that this pattern generally does not work well so another approach which is actually the one I first started with one building micro services is event sourcing which is an event centric approach to business logic and persistence and in many ways it's kind of a radical way of doing things basically your domain objects your orders your customers are persisted in the database as a sequence of events conceptually there's an event table so when an order is created and it an order created event is inserted into the table when it's approved an event is inserted when it shipped an event is inserted as well and this is the source of truth capturing the state of your orders so a very radical radically different approach to persistence as well and the way in which you write your business logic it's all in terms of generate a kind of generating events basically and then when you need to recreate in memory the state of the order you the system will load those events and replay them so where I say hibernate today right will reconstruct the in-memory state of an object by querying a bunch of tables and stitching those rows together into domain objects with the event sourcing this the events are queried and then they're replayed on the domain object and that the great example of that is if you have a bank account where the events are account debited and credited replay is really just summing up the debits and credits to reconstruct the balance but the same approach applies to all other domain objects as well one key requirement for your events store is that you need to load event by ID and just sort of one thing that I bet find irritating is like a lot of Kafka people describe Kafka as an event store but it does not it's an excellent message broker but it does not let you retrieve events by ID which is an essential requirement for for an event store the other part of the event store which Kafka is actually really really good at is the event store acts as a message broker click services can subscribe to those events so when they're inserted that they're simultaneously published at the same time however the message however the events store actually implements that and does it in an atomic fashion so so that that's basically satisfying the requirements that of kind of the saga patent as well where you've got an event where you need a message broker like functionality that guarantees ordering and so on so when I first started building micro services this was how I built them and then it was like oh they're using events and that then later on I realized oh wait this is choreography based sagas and as you're gonna see it's like oh wait event sourcing isn't the only way of publishing event but event sourcing has some interesting characteristics it does preserve the history of domain objects which lets you kind of do auditing it lets you kind of ask answer the question what was the state of this domain object two weeks ago which might be good for auditing and so on but then it is a very different way of programming also you've got potentially long-lived events and they're at allinger's around managing the the schema evolution and then the events store basically work forces you to use CQRS it's not directly querying unless you want to know give me the events by primary key and then it's implementing choreography based sagas is really really natural but other kinds of orchestration based sagas are more challenging so for that reason another approach that's really really appealing is to use the traditional persistence JPA mybatis pick your favorite with what's known as the transactional outbox pattern so the way that works is you know like here's you this is like spring data for JPA example or to get saved and then it just explicitly publishes an event or so it thinks in reality what's happening that event is being inserted into an outbox table as part of the database transaction that is updating the order and because it's part of the same asset transaction you have the atomicity guarantee that you need so all messages that the that the track that the service wants to send ends up in this outbox table there's then a separate process that is reading the outbox table somehow and publishing those messages to the message broker so it's like a two-step process and I first actually heard about this in the context or something very analogous to this in the context of ebay like ten years ago so in many ways this is not a radical idea so there's two ways of actually getting the messages out of the outbox table and publishing them to the message broker so one option is to tail the database transaction log which sounds like kind of like weird and crazy I mean it the challenges is that it's it's very how you do that is very very database specific you know do you it's with my sequel it's the bin log with Postgres it's the right ahead log DynamoDB has table streams and so on but once you kind of just accept that it's a it's a legitimate approach it ends up being quite straightforward to do that and just one of the things that my open source project does the other option which is sort of universally applicable to jdb save JDBC databases is pull the message table every n milliseconds do a select star from passage where message is unpublished published the message to the mess to the message broker and then update those messages to mark them as having been published and so but there are issues around this like with well what about poling frequency and so on and some of you might be wondering well what happens if you crash before after querying the method well after publishing the messages to the message broker and but before marking them as having been updated and what that means is sort of two things yes in a failure scenario with once with sort of a simple implementation yes that does mean that messages might get written to the message broker more than once but given that message handlers are almost always written to detect and discard duplicates because message brokers anyway can deliver the same message more than once it ends up not being a problem for the most part so anyway so that that so you've got those two approaches so like the open source project I work on we support Postgres right ahead log my sequel bin log but then you can just use polling for like Microsoft sequel server or Oracle or pick whatever database anyway so that sort of transactional messaging is sort of that kind of the technical foundation for making sagas and making CQRS work so that's my talk so it's sort of in summary right in a micro service architecture you you're using asynchronous messaging to kind of solve these the distributed data management problems in a micro service architecture service is a publishing event so this is the event-driven part to implement choreography based sagas and and CQ and CQRS but orchestration based sagas use asynchronous to request reply so an entirely different form of messaging and then sort of one of the key technical foundation for this is that services need to be a need to atomically update state and send a message so one way to do that is event sourcing but a more sort of general approach what I think is like if you're adopting micro services is far easier to to embrace is actually the transactional outbox pattern so yeah so that's my talk thank you for listening and uh yeah my book if you want a discount on it got a plug my book right and go to that link and I should say oh don't forget to vote provided you like this talk of course and you can ask questions and if I don't answer them today I promise I will write a blog post within the next 50 years that will answer them I get around to things eventually and I'm doing a book signing later today to a client and I'm in the break this afternoon and tomorrow lunchtime there's like some micro service discussion table thing hang out so anyway thanks thanks for listening hope that you found this useful [Applause]

Channel: GOTO Conferences

Views: 82,372

Rating: 4.9072165 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, GOTOchgo, GOTO Chicago, Chris Richardson, Microservices, CQRS, APIs, Events, Event Streaming, Event Sourcing, Asynchronous Microservices

Id: kyNL7yCvQQc

Length: 50min 37sec (3037 seconds)

Published: Tue Sep 17 2019

Reddit Comments

[u/mto96]

Check out this 50 minute talk from GOTO Chicago 2019 by Chris Richardson, creator of the original CloudFoundry.com and author of 'POJOs in Action' and 'Microservices patterns'. I've dropped the full talk abstract below for a read before jumping into the talk:

​

The microservice architecture functionally decomposes an application into a set of services. Each service has its own private database that’s only accessible indirectly through the services API. Consequently, implementing queries and transactions that span multiple services is challenging.

In this presentation, you will learn how to solve these distributed data management challenges using asynchronous messaging. Chris will share with you how to implement transactions using sagas, which are sequences of local transactions. You will learn how to coordinate sagas using either events or command messages. Chris will also explore how to implement queries using Command Query Responsibility Segregation (CQRS), which uses events to maintain easily queried replicas.