title: Architecture: using a separate queue for error handling?
body: <p>We have a small microservice which sole purpose is to receive messages through a queue and send these to an external system. The messages can come from any number of other services and the service has no knowledge about the content of the message. The external system can either accept or reject this message. I see a number of options to deal with the responses of the external system:</p>
  
  <ul>
  <li>put the responses on the same queue used to receive the messages</li>
  <li>put the responses on a different queue</li>
  <li>put the successful responses on a different queue and the error responses on yet another queue </li>
  </ul>
  
  <p>I'm inclined to choose the third option to separate concerns and not disturb a happy flow with an error flow, but would like feedback why this could be a bad choice.</p>
  
  <p>Are there any resources available documenting best practice solutions for these kinds of problems? </p>
  
  <p>(I am aware above could be rewritten to a service reading from the queue and storing the message in a db, asynchronously sending the messages to the external system and storing the response in a db, publishing an event to indicate the message was processed and developing an api to allow to retrieve the response from the db, but that would require an extra db, more work and more resources, which in my opinion would be overkill)</p>