title: AWS SQS Asynchronous Queuing Pattern (Request/Response)
body: <p>I'm looking for help with an architectural design decision I'm making with a product.  </p>
  
  <p>We've got multiple producers (initiated by API Gateway calls into Lambda) that put messages on a SQS queue (the request queue).  There can be multiple simultaneous calls, so there would be multiple Lambda instances running in parallel.</p>
  
  <p>Then we have consumers (lets say twenty EC2 instances) who long-poll on the SQS for the message to process them.  They take about 30-45 seconds to process a message each.</p>
  
  <p>I would then ideally like to send the response back to the producer that issued the request - and this is the part I'm struggling with with SQS.  I would in theory have a separate response queue that the initial Lambda producers would then be consuming, but there doesn't seem to be a way to cherry pick the specific correlated response.  That is, each Lambda function might pick up another function's response.  I'm looking for something similar to this design pattern: <a href="http://soapatterns.org/design_patterns/asynchronous_queuing" rel="noreferrer">http://soapatterns.org/design_patterns/asynchronous_queuing</a></p>
  
  <p>The only option that I can see is to create a new SQS Response queue for each Lambda API call, passing in its ARN in the message for the consumers to put the response on, but I can't imagine that's very efficient - especially when there's potentially hundreds of messages a minute?  Am I missing something obvious?  </p>
  
  <p>I suppose the only other alternative would be setting up a bigger message broker (e.g. RabbitMQ/ApacheMQ) environment, but I'd like to avoid that if possible.</p>
  
  <p>Thanks!</p>