Chapter 1. Foundational RabbitMQ
Figure 1.1. RabbitMQ clusters use the native Erlang inter-process communication mechanism in the VM for cross-node communication, sharing state information and allowing for messages to be published and consumed across the entire cluster.
Figure 1.2. Before: once a user has logged in, each database is updated with a timestamp sequentially and dependently. The more tables you add, the longer this takes.
Figure 1.3. After: using RabbitMQ, loosely coupled data is published to each database asynchronously and independently, allowing the login application to proceed without waiting on any database writes.
Figure 1.4. When communicating with a database, a tightly coupled application must wait for the database server to respond before it can continue processing.
Figure 1.5. A loosely coupled application allows the application that would have saved the data directly in the database to publish the data to RabbitMQ, allowing for the asynchronous processing of data.
Figure 1.6. By using RabbitMQ, the publishing application doesn’t need to be changed in order to deliver the same data to both a new cloud-based service and the original database.
Figure 1.7. By leveraging RabbitMQ’s federation plugin, messages can be duplicated to perform the same work in multiple data centers.
Figure 1.8. Bidirectional federation of data allows for the same data events to be received and processed in both data centers.