Service request/response: would you use routing keys and store messages in the same RabbitMQ queue?

For example, I've implemented a search indexing service, which receives search requests and produces responses using messages.

Currently I've defined a queue to enqueue search requests and other one to enqueue search results.

Would you refactor this to just enqueue to an unique queue where messages have a request and response routing keys? Or is this overusing RabbitMQ on this particular case?

Solution

After some research, I feel that this should be a good practice:

There should be a single exchange. For example searchrequest.
Two queues, one for incoming requests and other for responses.
The whole single exchange should route message from requests or responses queue based on a given routing key.
When some service does a search requests, sends a message to searchrequest exchange and request routing key. When search indexing service creates a response, sends it to searchrequest exchange too but it publishes the response message with response routing key.

At the end of the day, using routing keys to publish messages to same queue on my particular case doesn't seem to be natural. It feels hacky.