Wednesday, May 24, 2017

AWS SQS Design Considerations

Few things came to my mind about AWS Simple Queueing Service (SQS) -

These are highly subjective based on the type of Service Architecture.

1. receive_message() and delete_message() are two different things. Imagine if a server dies in multi-server cluster environment, the message in queue was received by other server which was alive (It doesn't call the delete_message() ), when the first server comes back to life, it will receive the message again (after natural polling), but it is already processed by another server & sent further in the Service Flow. The recovered server can again process the same message and might call the Service Flow again. Should delete_message() be called always no matter who processes the message?

2. A logic is needed to handle above scenario. Who should delete the message from the queue?

3. There can be a delay between SQS Load Balancing queue message appearance, it should check and recheck again and again to arrive at the empty queue again, so that the messages are not missed.

4. In FIFO with load balancing, the message will be delivered in same order?

5. Amazon distributes data in SQS accross multiple data centres, after populating the messages, what should be the optimum wait time to successfully query the list of messages in SQS?

6. Simple method to prevent duplicate messages in SQS?

I will explore more on this topic. This page will act as a placeholder for my SQS/SNS thoughts.


No comments:

Post a Comment