Great feedback, thanks :)

Thanks for the feedback, I think this is actually just a problem with the diagram. Between each of the points of integration there would be some kind of event bus, so if the order service "failed" then all that would mean is that events aren't being published. This is good feedback though, Ill take it into future version of the talk. Thank you.

​@@serverlessjames ​ To be honest, I liked the talk overall, specially the concept that each service doesn't need or should be aware of everything that is happening. My criticism is mainly on the architecture with this example, which I feel doesn't take fully advantage of an event driven system and has a "bottleneck" by design. And that is even if you put the EventHub in the middle, it's still events that you go back and forth between the Order Processing Service and the others. Using this scenario in question, my point is that "Order Processing Service" should handle the order and trigger a "new order" event when a new order has been received and that's it. After that, Kitchen is most likely listening to that so it starts cooking. Kitchen can than issue an event "CookingStarted" or whever which includes the expected duration in case other services needs to prepare in advance (such as calling a courier) and another event at the end "CookingFinished". "Order Processing Service" could be listening to these just to update a customer view or whatever, but "Delivery Service" and "Pick-Up" services would have listened directly "new order" to know the the delivery type and than just wait for the "CookingFinished" event. This way, you have a natural flow of responsibility, where even if "Order Processing Service" dies in the middle of an order, the Kitchen doesn't care anymore is already cooking, and the delivery services don't care either as all they care is for the kitchen to finish cooking :) I have low experience as a programmer, however I'm a but addicted to minimizing hard dependencies and allow for flexibility in my solutions, by using architectures such as the Onion Architecture :)

Yeah I think you're absolutely right, and later in the talk I think I go through it in this same way. I'm going to refine the diagram for the next time I give a similar talk, so thankyou.

While you are at it :) there's a typo in 10:20, should be "its" instead of "it's".