A k8s cron job(Spring boot microservice) would come up every night to handle the error messages from the above status_queue and handle only 500 int server errors FOR RETRY.Needed some expert advice on the below approach if there would be any issues: SO basically : app_topic -> app_queue -> Microservice Error -> status_topic -> status_sqs We did this with a view in mind that once the end to end application development is done for happy scenarios, we will handle the messages in the status_queue in such a way that Production support team has a way to remediate both 500 or 400 errors. A SQS named status_queue is subscribed to this topic. In both these scenarios, we are dropping a message to the SNS topic named status_topic.Categorised the exceptions as 500(int server errors) and 400(bad req) category errors.As part of the happy flow,these microservices listen to AWS SQS(suppose app_queue) which is subscribed to AWS SNS topic(suppose app_topic).įor exception scenarios we have implemented something like below: 4.We have implemented an event driven architecture application which has around 7 spring boot microservices. The permission will be there, and the flow will work as expected. This way, it will not receive the messages we publish on the topic.īut we can perform the same action from the SQS service page. The subscription process will not always add the necessary permissions to the access policy of the queue. When we want to add an SQS queue as a subscriber to an SNS topic in the Console, we can do it in one of two ways. This permission was missing from the access policy when we tried to add the subscription from the SNS service page. This statement allows test-sns-topic to SendMessages to `test-queue. SNS is not an identity, so we should use the access policy here.īy default, the access policy of the queue test-queue looks like this: The access policy is a resource-based policy, and it must contain the principal element that specifies who or which service can send messages to the queue. The reason is the SNS will not add the relevant permissions to the SQS queue’s access policy. At the end of a long day, one can spend precious minutes (hours) debugging why the Lambda function is not running after we have published a message on the topic. Select Amazon SQS for Protocol, specify the ARN of the queue, and we should be good to go. We select the topic and choose Create subscription in the Subscriptions section. To continue with the serverless momentum, assume that a Lambda function polls the queue and does something with the message. The task is to subscribe the queue to the topic. Please see the references section at the end if you need help. This blog post will not explain how we create a topic or a queue. When we use CDK to create our infrastructure, the framework will take care of the permissions.īut what if we need to put together a quick demo in the Console? It should work, too, right? 2. Even AWS services can’t call other services if the relevant permissions are missing. When the consumer can process the messages slower than the producer sends them, queues can temporarily store them until the consumer eventually processes them. One use case of queues is for buffering purposes. We can add multiple different subscribers to a topic, for example, email addresses, phone numbers, or SQS queues. The key service that publishes messages to its subscribers is Simple Notification Service (SNS). Say we want to build a fanout serverless architecture. How we add it as a subscriber to the topic via the AWS Console matters because the SQS access policy doesn't always contain the correct permission statement. When we want to subscribe an SQS queue to an SNS topic, it must have the relevant permissions to send messages to the queue.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |