Qual è il posto migliore per creare Binding e Queue su comunicazione RPC: Consumer o Producer?

Stavo parlando con parte del mio team sulla responsabilità di chi possiede la creazione di Binding e Queue. Stiamo usando il framework Spring.

In comunicazione asincrona concordano che la responsabilità di creare il Binding e la Coda è del Consumatore. Fino a qui, siamo tutti d'accordo.

Ma capiscono che questo non è vero per la comunicazione di sincronizzazione (RPC - Remote Procedure Call).

Preferiscono questo modello:

Producer1: Exchange, RoutingKey, Binding (RoutingKey, Queue)
Producer2: Exchange, RoutingKey, ​Binding (RoutingKey, Queue)
Consumer: Queue

Le loro ragioni:

1. Il produttore invia un comando (non un evento , come nella comunicazione asincrona). Poiché il produttore è il principale interessato alla risposta, l'impostazione rimane su di lui.
2. Il consumatore deve solo conoscere la coda. Non importa chi gli manda il messaggio.

Tuttavia, non vedo in questo modo.

Il modello che supporto è:

Producer1: Exchange, RoutingKey
Producer2: Exchange, RoutingKey
Consumer: Exchange, Binding (RoutingKey, Queue)

I miei motivi:

1. La conoscenza di Binding deriva da chi consuma la coda, come nella comunicazione asincrona
2. Un singolo punto per dichiarare e modificare Binding e Queue. Quindi, questa configurazione è fatta solo nel consumatore, ma nel loro approccio è duplicato tra i produttori. Mi è già successo di cambiare il nome della coda, il DLQ Binding e Queue e il DLQ della chiave di instradamento, e con l'impostazione su Consumer ho cambiato questo in un posto unico.
3. Se si desidera implementare un DLQ, è naturale che il listener DLQ si trovi nel consumer, con anche il binding di DLQ e Queue of DLQ. Non ha senso per me dichiarare il binding DLQ e la coda DLQ in ogni produttore.
4. Ogni esempio di comunicazione Async e Sync (RPC) nella documentazione ufficiale di RabbitMQ segue lo schema che supporto. Non ho trovato alcuna dichiarazione circa la configurazione diversa dalla sincronizzazione asincrona per la comunicazione e le ragioni di tale cambiamento.
5. La configurazione è più semplice da comprendere, perché la configurazione asincrona e di sincronizzazione segue la stessa idea: Binding e Queue on Consumer.

Quindi, qual è l'approccio consigliato?