‫Hey, welcome back.
‫Now, it's time for us to learn
‫about the most fundamental architecture building block
‫for asynchronous architectures, the message broker.
‫We will start with getting the motivation
‫for message brokers by exploring some use cases
‫where an asynchronous architecture can provide us
‫with more benefits and better capabilities.
‫And finally, we'll learn what kind
‫of quality attributes message brokers can add to our system.
‫So what is a message broker and why do we need it?
‫If we recall from the previous lecture where we learned
‫about load balancers, you probably noticed
‫that in each case,
‫when we mentioned two applications talking to each other,
‫either directly or through a load balancer
‫there was always an implicit assumption
‫that both the sender application
‫and the receiver application maintained
‫an active connection.
‫This implies that they were both healthy
‫and running in the same time.
‫This type of communication
‫is called synchronous communication.
‫While synchronous communication
‫is the most straightforward type
‫of communication between services, it has a few drawbacks.
‫The first drawback that we already mentioned is the fact
‫that both application instances that establish
‫the communication with each other have to remain healthy
‫and maintain this connection to complete the transaction.
‫While it's easy to achieve
‫when we have two services that exchange very short messages
‫that take a very short time to process and respond to
‫things get a lot more complex
‫when we have a service that takes a long time
‫to complete its operation and provide a response.
‫As an example, let's consider a system that sells tickets
‫to different shows
‫or performances offered by different theaters.
‫Let's assume that we have two services.
‫The first service simply provides the front end
‫to the user and get requests for purchasing tickets.
‫The second service fulfills the order
‫by reserving the ticket through an external API.
‫Then it builds the user
‫by communicating with a credit card company.
‫And in the end, it may send a confirmation email
‫or talk to an external service
‫that would send a physical ticket to the user.
‫Now, while the ticket's reservation service
‫is doing its job, the front end service will have
‫to maintain an open connection and wait for our response.
‫But while it's waiting
‫for the response from the tickets reservation service
‫it's also holding the user in suspense
‫because until the ticket is reserved
‫and the user is successfully built
‫we won't know if the operation is successful.
‫But besides the fact that the operation itself
‫even when successful may take a long time
‫things can get a lot worse
‫if the application server that performs all
‫those operations suddenly crashes
‫and we need to start over.
‫Another drawback of synchronous communication is
‫that there is no padding
‫in the system to absorb a sudden increase
‫in traffic or load.
‫For example, let's say we have an online store
‫that has two services just like before.
‫One for receiving direct traffic from users
‫and another to fulfill the actual purchase.
‫And let's also assume
‫that we're running a limited time promotion
‫for one of our products.
‫That promotion results in manual requests from users
‫to our front end service, which we can easily handle.
‫But it also results
‫in a very large number of purchase fulfillment requests
‫to our order fulfillment service
‫which we cannot easily handle even if we scale that service
‫to many server instances.
‫The reason for that is simply because fulfilling each order
‫involves many operations that take a very long time.
‫All those scenarios can be easily solved
‫with an architectural building block
‫called message broker.
‫A message broker is a software architectural building block
‫that uses the queue data structure to store messages
‫between senders and receivers.
‫To be clear unlike a load balancer that can be easily used
‫to take external traffic from a client application
‫a message broker is an architectural building block
‫that is used inside our system
‫and is generally not exposed externally.
‫In addition to simply storing
‫or temporarily buffering the messages,
‫message brokers can provide additional functionality
‫such as message routing, transformation, validation
‫and even load balancing.
‫However, unlike load balancers message brokers
‫entirely decouple senders from the receivers
‫by providing their own communication protocols and APIs.
‫Message brokers are the fundamental building block
‫for any type of asynchronous software architecture.
‫When we have two services communicating with each other
‫through a message broker, the sender doesn't have to wait
‫for any confirmation from the receiver
‫after it sends the message to the message broker.
‫In fact, the receiver may not even be available
‫to take any messages while sender, send that message.
‫So in the case of the ticket reservation system
‫the end user may get an acknowledgement immediately
‫after placing the order.
‫And later it will get an email asynchronously
‫with an official confirmation for purchasing the ticket
‫after the ticket reservation service
‫actually completes the transaction.
‫By using the message broker
‫we can break the ticket reservation service
‫into multiple services.
‫Each for one stage in the transaction
‫and each pair of services is also decoupled
‫from each other by a message broker.
‫Another important benefit that a message broker provides us
‫with is buffering of messages to absorb traffic spikes.
‫In our online store scenario,
‫when we have a lot of orders in a short period of time
‫the front end service may simply decrement a counter
‫in a database for the number of items left in stock
‫while the actual orders are stored
‫inside the message brokers queue.
‫And those orders can be fulfilled one by one
‫after the sale is already over
‫and the traffic to our store goes down.
‫Most message broker implementations
‫also offer the published subscribe pattern
‫where multiple services can publish messages
‫to a particular channel and multiple services
‫can subscribe to that channel and get notified
‫when a new event is published.
‫With this pattern we can take the same online store,
‫for example and without any modification into the system
‫we can easily add another service that would subscribe
‫to the orders channel
‫and feed that data to the analytic service.
‫This service would analyze the purchasing pattern
‫from different users and suggest certain products
‫to users in the future.
‫Similarly, we can add another service that for every order
‫from the user, it would send a push notification
‫to the user's mobile phone.
‫This way a user can be alerted
‫if a purchase order was placed from their account.
‫And later, just as easily we can add another service
‫that for every purchase from a user would schedule a survey
‫or request a review a certain time
‫after the purchase has been made.
‫And as you can see with this pattern
‫all those services were added
‫without any modifications to the system.
‫So now that we understand all the benefits and capabilities
‫of a message broker, let's speak more concretely
‫about what quality attributes we get
‫from using a message broker in our system.
‫A message broker adds a lot of full tolerance to our system
‫since it allows different services to communicate
‫with each other while some
‫of them may be unavailable temporarily.
‫Also, message brokers, prevent messages from being lost
‫which is another characteristic of a full tolerance system.
‫All this additional full tolerance helps us provide
‫with higher availability to our users.
‫Additionally, since a message broker can queue
‫up messages when there is a traffic spike
‫it allows our system to scale to high traffic
‫without needing to make any modifications to the system.
‫Now it's worth noting that
‫while a message broker provides us
‫with superior availability and scalability
‫we do pay a little bit in performance
‫when it comes to latency.
‫The reason for that additional latency is a message broker
‫at a significant indirection
‫between two services, in comparison
‫to the straightforward synchronous communication
‫even through a load balancer.
‫But generally, this performance penalty
‫is not too significant for most systems.
‫In this lecture, we've learned learn
‫about a very important architectural building block
‫which is fundamental
‫to any asynchronous software architecture,
‫the message broker.
‫We got the motivation for using a message broker
‫by comparing it to the synchronous communication
‫we typically use between services directly
‫or through a load balancer.
‫Later, we talked about the different benefits
‫and capabilities that a message broker provides us with
‫such as asynchronous architecture, buffering, and others.
‫And finally, we talked
‫about the two main quality attributes that we get
‫from using a message broker.
‫Those quality attributes are high availability
‫that comes thanks to the superior full tolerance
‫to service outages and message loss and high scalability
‫which comes mainly due to the ability to buffer messages
‫when there are sudden spikes in the load on our system.
‫I will see you in the next lecture
‫with another exciting architectural building block.