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

Поделиться
HTML-код
  • Опубликовано: 8 апр 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 RUclips 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.
  • НаукаНаука

Комментарии • 16

  • @hooleyt
    @hooleyt 11 дней назад

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

  • @Fikusiklol
    @Fikusiklol 19 дней назад +1

    Great talk!
    Thanks, James :)

  • @parvagrawal1043
    @parvagrawal1043 23 дня назад

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

  • @b5stephen
    @b5stephen Месяц назад +1

    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.

  • @alexbeloff4618
    @alexbeloff4618 18 дней назад

    Great talk, thanks!

  • @IgorKomarynskyi
    @IgorKomarynskyi 24 дня назад

    roontime! 😆I love it!

  • @joeedh
    @joeedh Месяц назад +1

    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.

  • @wormB1
    @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).

  • @rngesus8057
    @rngesus8057 Месяц назад +2

    👌

  • @joeedh
    @joeedh Месяц назад +1

    Deadlocks? Cycles?

  • @ralmslb
    @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
      @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
      @ralmslb Месяц назад +1

      ​@@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
      @serverlessjames Месяц назад +1

      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
      @alvaromoe Месяц назад

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