@jkarneges Ok. How about this? Behind the ELB, there are 2 instances running pushpin at port 80 and apache at port 9000 (configure pushpin route all the requests to localhost:9000). I haven't used haproxy yet, so I don't know how it would not be a single point of failure.
yes. you could run haproxy on your own ec2 instances for example. to avoid single point of failure you need multiple instances and dns round robin, or an active/standby style setup where an elastic IP can migrate to a standby instance if the active fails
@jkarneges Not all the API calls need LONG POLLING or WEB SOCKET connection, only few does. Therefore, in that context, for those LONG POLLING API calls, the actual response is sent by another instance, typically an APP server.
@jkarneges Does the ELB option would help me here?
@jkarneges Other question I have is on the APP server responding back to pushpin - it really does know which pushpin server to respond to (if there are two pushpin instances). This was not a problem in the DEV env as there are just one instances each.
@jkarneges Yes, 55 secs is more than enough for long polling
if you are pushing a lot of data and really only want the data to go to the pushpin servers with listeners then this is possible too but may require some extra work (like sending to pushpin's zmq port)