We will implement a system , which will receive quite a lot of requests through web service interface. We will have to queue the requests and process them asynchronously. Consequently we will have to have also some output queue with responses (QR). The web service client will have the possibility to query his (and only his) processed requests in QR using another web service method. Also, client will have the possibility to find the exact response from the QR by providing id of the request (returned after posting the request). Also, client will be abel to delete the request from QR. There will be cca 60 requests per second.
The question is how to implement QR. We need reliability and durability (nothing is allowed to be lost).
Now the question how this can be implemented ... . There are several options, which come to my mind:
- Using RDBMS - but this is far from ideal as the performance would not be ideal
- employ something like Redis or memcached - having one incoming queue in redis and for each client list with processed items (responses), but i am sceptical about reliability and durability. We can not afford to lose any of the requests or responses.
- Some other noSQL solution ?