Joe goes full shock jock, but only for a moment. Allen loses the "Most Tips In A Single Episode: 2021" award, and Michael didn't get the the invite notification in this week's episode. The full show notes for this episode are available at https://www.codingblocks.net/episode168. Sponsors Datadog – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.Shortcut - Project management has never been easier. Check out how Shortcut (formerly known as Clubhouse) is project management without all the management. Survey Says Well...no survey this week, but this is where it would be! News This book has a whole chapter on transactions in distributed systems Thank you to everyone that left a review! "Podchaser: alexi*********, Nicholas G Larsen, Kubernutties,iTunes: Kidboyadde, Metalgeeksteve, cametumbling, jstef16, Fr1ekAudible: Anonymous (we are like your mother - go clean your room and learn Docker) Atlanta Code Camp is right around the corner on October 9th. Stop by the CB booth and say hi! (AtlantaCodeCamp.com) Maintaining data consistency Each service should have its own data storeWhat about transactions? microservices.io suggests the saga pattern (website)A sequence of local transactions must occur Order service saves to its data store, then sends a message that it is doneCustomer service attempts to save to its data store…if it succeeds, the transaction is done. If it fails, it sends a message stating so, and then the Order service would need to run another update to undo the previous action Sound complicated? It is…a bit, you can't rely on a standard 2 Phase Commit at the database level to ensure an atomic transactionWays to achieve this - choreography or orchestration Choreography Saga - The Order Service receives the POST /orders request and creates an Order in a PENDING state - It then emits an Order Created event - The Customer Service’s event handler attempts to reserve credit - It then emits an event indicating the outcome - The OrderService’s event handler either approves or rejects the Order Each service's local transaction sends a domain event that triggers another service's local transactionTo sum things up, each service knows where to listen for work it should do, and it knows where to publishes the results of it's work. It's up to the designers of the system to set things up such that the right things happenedWhat's good about this approach? "The code I wrote sux. The code I'm writing is cool. The code I'm going to write rocks!" Thanks for the paraphrase Mike! Orchestration Saga - The Order Service receives the POST /orders request and creates the Create Order saga orchestrator - The saga orchestrator creates an Order in the PENDING state - It then sends a Reserve Credit command to the Customer Service - The Customer Service attempts to reserve credit - It then sends back a reply message indicating the outcome - The saga orchestrator either approves or rejects the Order There is an orchestrator object that tells each service what transaction to runThe difference between Orchestration and Choreography is that the orchestration approach has a "brain" - an object that centralizes the logic and can make more advanced changesThese patterns allow you to maintain data consistency across multiple servicesThe programming is quite a bit more complicated - you have to write rollback / undo transactions - can't rely on ACID types of transactions we've come to rely on in databasesOther issues to understand The service must update the local transaction AND publish the message / eventThe client that initiates the saga (asynchronously) needs to be able to determine the outcome The service sends back a response when the saga completesThe service sends back a response when the order id is created and then polls for the status of the overall sagaThe service sends back a response when the order id is created and then submits an event via a webhook or similar when the saga completes When would you use Orchestration vs Choreography for transactions across Microservices?Friend of the show @swyx works for Temporal, a company that does microservice orchestration as a service, https://temporal.io/ Tips for writing Great Microservices Fantastic article on how to keep microservices loosely coupled https://www.capitalone.com/tech/software-engineering/how-to-avoid-loose-coupled-microservices/ Mentions using separate data storage / dbs per service Can't hide implementation from other services if they can see what's happening behind the scenes - leads to tight coupling Share as little code as possible Tempting to share things like customer objects, but doing so tightly couples the various microservices Better to nearly duplicate those objects in a NON-shared way - that way the services can change independently Avoid synchronous communication where possible This means relying on message brokers, polling, callbacks, etc...
