decoupled • Not scalable in an efficient way • Bad for exceptions handling • Less reliability • Not flexible • Is it essential to send the notifications there ? 5
should encapsulate everything consumers might need • In our example use case : ◦ The id / uuid of the reply ◦ The content of the notification and the query to find the recipients 15
message between the producer and the consumer • Objective : decoupling the awareness between producers and consumers • In our example use case : ◦ An existing one 17
message • This program logically does the expensive task • In our example use case : ◦ Our application ◦ In a dedicated service ◦ Another application ◦ In another language ◦ On another server 18
takes a few milliseconds ◦ Sending the notifications does not block the response • Decoupled : ◦ Not perfect in our example but : ◦ The publish and consume parts are totally separated ◦ So extracting the consumer would be way more easier 22
to spawn new instances of our consumer • Better exceptions handling : ◦ Because of the retry mechanism ◦ And the dead letter exchange mechanism ◦ By splitting one message into several small ones 23
(producer) is down, all the currently waiting messages can still be processed • Flexible : ◦ We can replace our current consumer implementation ◦ We can add a new behavior with a new consumer 24
for the AMQP protocol • The most widely deployed Open Source message broker in the world • Written in Erlang, a concurrent and functional programming language 31
an exchange • The exchange knows what to do with the message (forwards it to one or several queues, or ignore it) • 4 Different types : direct, topic, headers and fanout 33