I'm currently trying to design my architecture and not sure how to set it up.
I have a lot of automated clients which I need to send messages to.
A user will connect to my server to send commands to a remote client. There are 2 key points:
- The command has to be sent ASAP
- It has to be 100% reliable. If one EC2 crashes - another instance has to be able to send the commands (they might be delayed - but they will not be lost).
The service is targeted toward corporate organization so scalability and reliability is the key factor.
All remote clients are registered in the service using a serial number and optional group tags (organization for example)
My first idea was to run few node.js instances which will listen to SQS queue and then dispatch the incoming commands to the remote clients. A command might be sent to a specific client (by its serial number) or to a group of clients (by a shared group tag - for example, a command to all AT&T clients).
The problem is that some times, the node.js servers might have an infinite loop trying to read from the SQS queue - resulting in extra charges for nothing.
If I'll use RDS to store them, again - the nodes might check the DB too many times without actual data - resulting in extra charges.
Basically, I'm thinking of few web services to handle the incoming requests (which will store them in SQS or some sort of database) and then I'll have some workers (on the same EC2 instance or another one) which will take care of dispatching the saved commands.