[00:01] so one of the leading patterns that we use for microservices is what we call event driven architecture event driven architecture has many benefits over the API driven architecture and we're going to have a look at those today so when we
[00:13] different microservices you need a way for them all to talk to each other one way to do this is with messages we can have one service that adds a message to that listens to that queue and then acts on it when it receives it this is what
[00:27] and it does differ slightly from the event driven architecture that we're looking at today the main difference is that in event driven architecture our service will send an event after the event has happened the service raising
[00:39] after the event has been raised it doesn't care whether there's another state has changed in your application then an event is raised the event might be someone logging into your application or they might be performing a certain
[00:52] action the key here is that the service that's raising the event isn't reliant still work without it the event themselves are slightly different to messages as well a message is usually a command to do something it is designed
[01:06] instructions on what needs to be done this could be sending an email for example or running some other back-end process with an event there's not usually any instructions it's just information on what has been performed
[01:19] handled are slightly different as well with messages once a message has been processed is then deleted from the queue ready for the next message to come along events on the other hand are immutable they can't be changed they can't be
[01:32] of what's happened in your application so we now have a service that is the other services to respond to them we do this using an event broker your other services subscribe to this event broker and the broker is responsible for
[01:46] pushing events out to the Subscribe services this is often referred to as the publisher subscriber model or Pub sub for short when a service subscribes to the event broker they specify which events they are interested in it is then
[01:59] the brokers responsibility to work out which events the services are received this is usually done with a checkpoint so in an event-driven architecture there's three main components there's the producer which publishes the events
[02:11] the broker which manages which subscribers get which events and finally there's the consumer which subscribes to the event broker to receive the events now that we've got a good idea of what event driven architecture is let's have
[02:24] it event driven architecture is used best when a process can be run consequence on the application raising the events this can be really useful for things like auditing where you need to order every single action that the user
[02:39] does but the application itself doesn't need to know about the audit Trail or be run asynchronously such as maybe sending an email after someone's ordered something it's not usually critical that the customer gets their order email
[02:52] can be a couple of minutes late and it doesn't matter too much event driven architecture is also very good for data processing if if you've got a lot of application and you want to feed that into another system then you can do that
[03:06] really useful for training a machine learning algorithm based off of data have a look at some of the advantages of using event driven architecture as it does have quite a few benefits over the typical API driven model the first is it
[03:21] that decouples your components as the publisher doesn't need to know anything subscribing to its events they are completely decoupled from each other not only that but other services can be created they can subscribe to the same
[03:34] events all without the publisher needing to know compare this to one service calling another service over an API service one is now highly coupled to service two it needs to know how to call the API and what API contractor use the
[03:47] system is also less reliable if service 2 goes down then service one doesn't service 2 can go offline without affecting service one and then when then pick up where it left off the next benefit is that event driven
[04:01] dependency inversion the publishing service isn't dependent on any of the components aren't dependent on the publishing service both components are dependent on an abstraction which in this case is the events being raised as
[04:15] each service is dependent on an abstraction it allows you to reuse them as well as replace them with a different implementation without the other services being affected now the main benefit of event driven architecture is
[04:27] number of events being published increases then you can easily spin up more subscribers to process them you can also add more functionality such as auditing or data processing without slowing down the publishing service as
[04:41] with all things it's not a Clear Choice event driven architecture does have a need to be aware of the main issue is around data consistency when you're always going to be a delay between when the event is published and when your
[04:55] one of the trade-offs that you have to put up with if you want schedule ability delay by making sure that you've got enough subscribers to keep up with the events being published of course if they fall behind then there's going to be a
[05:09] between a service publishing an event and a subscriber picking up is minuscule is in the order of milliseconds but of course if your subscribers start falling increase and it might start to become noticeable by your users we call this
[05:25] going to be eventually consistent with what's being published however if you're not careful then eventual consistency can cause problems for the users using running an e-commerce site and you use an event-based system to manage the
[05:40] stock numbers as the system is eventually consistent this could allow two people to order the lowest item in stock or for example if you're using it to keep a history of the past orders a user could order something and then go
[05:52] their latest order won't be there if you're thinking about using an event-based system for scalability then sometimes you need to introduce a layer could store some information temporarily so that users aren't affected by any
[06:05] delays the second disadvantage for an event-based system is around duplicate keep a checkpoint however for performance reasons they don't keep a receive which means if your service goes offline when it comes back up it will
[06:19] checkpoint but it might end up receiving a few duplicate events as well you therefore need to make sure that your subscribers are item potent there is usually a unique ID on each of your events that can then be used by your
[06:32] servers to make sure you don't process the same event twice lastly event driven architecture like most systems designed for scalability is going to be a lot more complex you now have more components that you need to build and
[06:44] requirements on top of that your system is going to be a lot harder to debug when you do have problems arise all of these disadvantages are worth keeping in event based system if you're not having scaling problems at the moment and you
[06:58] don't foresee having them then chance an event driven architecture isn't worth more about software architecture you might like to watch this video on the microservice and which one you should pick thank you for watching this video
[07:10] please subscribe if you haven't already and I'll see you in the next video