So You Want to Build An Event Driven System? - James Eastham - NDC London 2024

This talk was recorded at NDC London in London, England. #ndclondon #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndclondon.com/
Subscribe to our TH-cam channel and learn every day:
/@NDC
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
#architecture #microservices #services
Making your system 'event driven' is a common consideration when building modern systems. Especially if these applications leverage serverless technologies. But what does that actually mean in the real world? What are the benefits of adopting this architecture style, what are the challenges and some of the tradeoffs?
In this session, you'll learn all about that and more with tips taken from building event driven systems in the real world. Starting from why, understanding what and plenty of practical things you can take away and use in your own applications. From the simple, through to some advanced integration patterns that this architecture style unlocks. to improve the resilience, extensibility and scalability of your systems.

[@Dmitry-Moiseenko]

Thank you for a great talk!

[@guillermoarroyo9465]

Great talk!

[@hooleyt]

Wow, this was incredibly thought-provoking and packed full of ideas, thankyou.

[@Fikusiklol]

Great talk!
Thanks, James :)

[@b5stephen]

Enjoyed this thanks! Really made me think about some decisions we made in a system I recently worked where we didn’t grasp what was possible with EDS and so fell back into REST ways of thinking.

[@parvagrawal1043]

Thanks for the great talk! Puts emphasis on what really drives the decisions when trying to build EDA

[@alexbeloff4618]

Great talk, thanks!

[@patrik.0]

Does your events include the whole aggregate root and everything within?
If not, how do you handle out of order events?

[@IgorKomarynskyi]

roontime! 😆I love it!

[@wormB1]

27:44 @serverlessjames it would be good to explain in the future how the order processing service got delivery address id to bake it in the event payload (is it a sync http get request from order processing service to delivery service, view model composition in the ui or something else).

[@serverlessjames]

Great feedback, thanks :)

[@whosgotrythm]

So how would the OrderProcessingService get the DelvieryId?

[@whosgotrythm]

Maybe capture the deliveryid in the session, so that OrderService knows the deliveryid?

[@joeedh]

Ok that quote at 51:15 is a bit much. It applies to a large number of software patterns most of which do that particulat thing better.

[@rngesus8057]

👌

[@joeedh]

Deadlocks? Cycles?

[@ralmslb]

7:50 This reversal is still bad in my perspective. You are creating a single point of failure unnecessarily.
Using this specific example, there is no reason why Delivery Service and Pick-Up service shouldn't be just dependent on the Kitchen service.

[@serverlessjames]

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.

[@ralmslb]

​@@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 :)

[@serverlessjames]

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.

[@alvaromoe]

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