title: What's the best architecture to use in this case? SQS? SNS? Combination of both?
body: <p>I have a central c# windows service on an EC2 instance inside AWS. Its job is to create tasks (instructions inside JSON) which are then sent down to individual windows services running on servers outside of AWS (think bricks &amp; mortar retail stores with a server in each store). </p>
  
  <p>These individual servers perform some processing based on the JSON task, and then send a message back to the central windows service inside AWS.  This design is currently using AWS SQS.</p>
  
  <p>I originally designed this using 1 SQS queue for messages to outside servers, and 1 SQS queue for messages coming back. Two queues in total. </p>
  
  <p>This design appears flawed however, as certain messages are for certain servers only, but in order to work out which message is for which server, the messages must be 'read' off the queue and the JSON examined, which then hides them from other servers polling for messages. This could lead to servers never getting to see their messages as they keep getting hidden by other servers. </p>
  
  <p>So what are my alternatives to this design? There are 400 servers outside AWS. I could have 400 SQS queues (one to each server) and then a single queue back to the central service? It just seems like SO many queues. </p>
  
  <p>I thought about using SNS? But then I'd still have 400 SNS topics right? One for each store? </p>