Building Autonomous Services
1 like563 views
This document discusses building autonomous microservices and provides assignments to practice designing services that are autonomous and event-driven. It introduces a simplified e-commerce domain with Catalog, Purchase, Sales, and Stock services and assigns tasks to modify the services to be more autonomous by subscribing to each other's events, updating internal state, and responding without direct communication. The assignments introduce concepts like process managers, event conversion, and using the reservation pattern to avoid concurrency issues. Questions are also provided throughout to help think through architectural challenges.
Building Autonomous Services
- 2. Ooph!
- 4. About the domain We have a much simplified warehousing domain with several services: 1. Catalog: Managing products in a catalog. 2. Purchasing: Receiving products that were previously purchased from a supplier. 3. Sales: selling to a customer products that we have in stock.
- 5. What are we doing here? Building autonomous services
- 6. Why do you want to use services?
- 7. Why do they have to be autonomous?
- 8. The problem is designing for autonomy
- 16. "What's the current state of something- something?"
- 17. The current state is the result of all past events
- 24. Solving the query issue 1. Services publish their events. 2. Other services subscribe to these events and update their own state accordingly. 3. They can build up any projection they like. This gives them the answers they need, without even asking.
- 25. tail -n 1 -f
- 26. Demo
- 27. Assignments • assignments/d+.md • Take a look at tips-and-tricks.md
- 28. Assignment 01 Create a projection to make Purchase autonomous
- 30. Questions How much data should you send with an event?
- 31. Questions When should you dispatch the events?
- 32. Questions Since you may have created a product before you started publishing events about it, your database may contain products, which are not in the stream. Hence, they are not stored as local products in the *Purchase* context. What would be needed to fix these inconsistencies? Think of/ discuss several strategies.
- 33. Questions What happens if you have a bug in your consumer and it doesn't process an incoming event correctly? Take a look at the code and comments of `Stream::consume()` and find out what its built-in mechanism is to counter this situation. What does this mean for the implementation of the consumer?
- 35. Process manager A consumer with side-effects
- 36. Process manager • Consumes every message (event) from the stream only once • Responds with any of the following: • Publishing a command • Producing a new event • Updating the status of a long-running process
- 37. Assignment 02 Create a process manager to make Stock autonomous
- 39. Questions Events potentially increase coupling between services. An event exposes details about the internal domain model of a service. When consuming events, services gather knowledge about each other's internals. This can lead to something known as a "distributed monolith". There may be runtime autonomy, but there will be lots of violations of D.R.Y. (the *knowledge* aspect of it). Come up with a way to prevent this.
- 40. Questions *Stock* currently doesn't store the names of the products, would it be better if it would? Think of some reasons for or against it.
- 42. Contexts • Transition of meaning: in one context "goods received", in the other context "stock increased". • Simplification of the message (same example), but also: "user added" as a summary of "user created", "user activated", "email confirmed", etc.
- 43. Upon receiving an event... • Produce a new event and add it to the stream. • This is a side-effect (i.e. it has effects noticeable on the outside of the service). • A "projector consumer" can rebuild its projection again and again, because it's internal to the service.
- 44. Assignment 03 Create a process manager to convert events
- 45. Stock stock level changed Catalog product created Dashboard Products + stock levels
- 46. Questions Couldn't we just use a "stock level changed" event? What about "stock level increased/decreased" events with a "current stock level" value?
- 47. Assignment 04 Auto-create a purchase order using an HTTP POST request
- 48. Questions Should we create a purchase order for the entire quantity of the sales order, or just the difference between the ordered quantity and the current stock level?
- 49. Questions What have we done?! We have created a direct, runtime dependency between *Sales* and *Purchase*... Not very smart, since the request for making a sales order might fail, even though the reason for this failure is a problem in *Purchase*. Can you think of a solution for the lack in autonomy?
- 50. Questions Consider the following situation: when we check for the current stock level of a product, immediately after that the product gets delivered to someone else. So when we try to deliver our sales order, it won't be possible anymore (and we should have added it to the purchase order after all!). What could we do about this?
- 52. The Reservation Pattern • In a system with concurrency, there's always the chance you're looking at stale data. • If you sell x items to a customer, they could be sold at the same time to another customer. • So: you first need to make a reservation.
- 53. Stock reservation • New sales order? Make a stock reservation. • When it's okay, commit and deliver the order. • When it's not okay, respond to it: make a purchase order.
- 54. Assignment 05 The Reservation Pattern
- 55. Sales sales order created make stock reservation Stock reservation accepted deliver sales order Sales Process Manager
- 56. Questions Isn't it bad to make HTTP POST calls?
- 57. Assignment 06 Taking actions when the stock reservation gets rejected
- 58. Sales sales order created make stock reservation Stock reservation accepted deliver sales order Sales Process Manager reservation rejected create purchase orderPurchase goods received make stock reservation
- 59. Assignment 07 Turn OrderStatus into a state machine
- 60. Assignment 08 Gain visual insight in the order status