# Proposed Implementation of Redis Queueus for Mediator

Aca-py, with the redis-queue plug-in, typically runs int he following configuration (assuming both inbound and outbound redis queues are implemented):

artifact acapy-redis {
    folder relay
    folder aca_py 
    folder deliverer
    database inbound_q
    database outbound_q
}

relay -right-> inbound_q
inbound_q -right-> aca_py
aca_py -right-> outbound_q
outbound_q -right-> deliverer

In this configuration, aca-py publishes the relay's endpoint to other agents, so messages are delivered to the relay and stored on the inbound Q.

Aca-py reads the inbound Q, processes messages and posts any responses to the outbound Q.

The deliverer reads the utbound Q and sends messages to other agents (or potentially to aca-py's controller, if the messages are webhooks).

This implementation is designed for the general case, however it doesn't work whereaca-py is acting as a mediator and is connecting (vis websockets) to mobile agents (specifically when a websocket session must be maintained across multiple messages).

For that scenario, the following implementation is proposed:

artifact acapy-redis {
    folder relay_deliverer
    folder aca_py 
    database inbound_q
    database outbound_q
}

relay_deliverer -right-> inbound_q
inbound_q -right-> aca_py
aca_py -down-> outbound_q
outbound_q -left-> relay_deliverer

In this implementation, the relay and deliverer processes are merged, so one process is responsible for both inbound and outbound messages.

This could support the mobile agent/websocket/sticky session scenario because the process responsible for maintaining the session (the relay/deliverer) is separated from the aca-py instance which is processing the messages.

If the websocket session needed to be maintained:

- the relay/deliverer would receive a message and post it to the inbound Q
- aca-py would process the message and post the response to the outbound Q
- the relay/deliverer would return the response, using the existing websocket connection

This complicates the deployment, as it introduces a new process (vs bundling this functionality into aca-py) however it simplifies the functionality in each process:

- the relay/deliverer is just responsible for communicating inbound and outbound messages (and has the extra requirement to maintain websocket sessions)
- aca-py is just processing inbound messages and returning outbound messages, interacting just with the two redis queues