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"?
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?
– Lorival Smolski Chapuis
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.
– Julio Faerman
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?
– Lorival Smolski Chapuis
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.
– Julio Faerman
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 =)
– Lorival Smolski Chapuis
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
– Julio Faerman