It is true that all of our interactions with RabbitMQ so far have been one way and asynchronous. It is also true that clients interacting with a service usually expect to receive a response. Reversing the publisher and consumer roles in the response phase requires the client to act as a publisher and the service as a consumer.
Different queues are used for requests and responses, as demonstrated in Chapter 2, Creating a Taxi Application, and illustrated in the following diagram:

Fig 5.1: A request-response interaction performed with message queues
In the following diagram, Fig 5.2, we can see the following:
- When a taxi driver confirms a booking request, a message is sent to the message broker with information about the driver (5).
- The application service receives the message (6), stores the information in the database (7), and confirms the booking with the mobile application, which is ultimately shown to the customer (8).
- At this point, the taxi needs...