Is there a need to do something to ensure queue delivery (SQS) in AWS?

Asked

Viewed 100 times

0

Assuming I have 2 Microservices "A" and "B" that are communicating through an SQS "F" queue".

The microservice "A" can fall, "B" can also fall, the question is: should I take into account that "F" could also fall?

If I take into account that "F" might fall, I could do something like put the message to be sent on a table in the bank and do the asynchronous sending via job to "F", but this seems an overengineering.

According to the link https://aws.amazon.com/pt/sqs/faqs/ AWS says: "Standard queues offer delivery at least once, meaning each message is delivered at least once."

I should just rely on SQS availability and track if something isn’t shipped instead of doing something to "secure delivery" to "F"?

aws microservices queue

1 answer

0


Usually it is not necessary to track the message deliveries, and it would be very difficult to do it more efficiently than SQS. If you need more control over message consumption, it might be more interesting to consider other services, such as Amazon Kinesis. Also note that the message retention limit in SQS is 14 days, messages need to be consumed in this period.

  • Thank you very much for your kind reply. I understand your point and I agree with you about traceability, my point is more about ensuring delivery of the message. If I didn’t have to worry about SQS availability, I wouldn’t have to do the tracking either. In a scenario where it is not possible to lose messages between one microservice and another, you should only rely on the availability of SQS or use Kinesis, as you suggested, or even Kafka, for example?

  • Once the customer sends the message, SQS stores it in various availability zones automatically. There is no guarantee or SLA in the legal sense, but the risk of losing a message is technically negligible. The problem is more on the side of your application. What if it has a bug and needs to reprocess the messages? What if you can’t process messages fast enough? Kinesis streams offer more functionality than an SQS queue.

  • Show... great point, I’m already taking into consideration that services A or B will drop. I would just like to make a simple communication via queue between 2 Microservices and make sure that a message will arrive at the destination. The AWS says that if she answered OK when it was posted in the queue, it will arrive in the queue... but even "technically despicable", it can happen that she did not respond OK and then I would just send again and the "guarantee" of message delivery in the queue would be solved. Makes sense, buddy?

  • For SQS not to answer OK it would have to be unavailable, which requires the simultaneous failure of multiple availability zones. As far as I know, this never happened and both Amazon and several customers use SQS intensely. If you want to go beyond that, you would want to consider a multi-region architecture, which hardly makes up for a case as you describe it.

  • 1

    Perfect friend! Your comments helped me a lot. The conclusion is that it really is an overengineering to create something to send to SQS in case of failure, as an SQS msg is saved in several availability zones. This info is in "https://aws.amazon.com/pt/sqs/". At the time of developing we defined a SQS record and I was not understanding where were these various zones, but reading "https://d36cz9buwru1tt.cloudfront.net/pt/wp/AWS_Cloud_Best_Practices_05252010.pdf" I understood that a Region has several zones, some have two others have more, but the magic is there. Thank you very much =)

  • That! More details on the overall AWS infrastructure on this https://aws.amazon.com/about-aws/global-infrastructure/ page and I also recommend this presentation https://www.youtube.com/watch?v=AyOAjFNPAbA

Show 1 more comment

Browser other questions tagged aws microservices queue

You are not signed in. Login or sign up in order to post.