Привет! Может у кого есть идеи как сделать: - у нас

есть микросервис который публикует мессаджи в SNS, и из SNS они направляются в очередь (SQS)
- эту очередь слушает другой микросервис (Lambda), который их процессит, во время процессинга он использут одно API, которое лучше не дергать более 60 раз в минуту
- если от первого микросервиса прилетает слишком много мессаджей (бывает что их генерится 500 в минуту) - то нам нужно как-то “притормозить” чтобы “слушающий” микросервис процессил их не все сразу, а по 30-60 в минуту

Варианты решения:
- ставить custom random delay во время отправки сообщения в SNS - к сожалению невозможно, custom delay опция есть только если шлешь напрямую в SQS (sqs.sendMessage) а в SNS такого нет (sns.publish)
- поставить concurrency limit у второго микросервиса в 1 - у меня почему-то в результате 1 мессадж оказался в deadletter queue, ну и concurrency=1 не гарантирует что оно в минуту не сделает больше 60

Я перетестирую сегодня с concurrency=1 но все равно это не идеально, - как можно притормозить получение мессаджей из SNS/SQS?

Привет! Я похожую проблему решал через написание сервиса на питоне, правда сервис ещё смотрел на другие SQS очереди и в зависимости от того насколько они загружены слал или тормозил отправку. Для лямбды мне тоже интересно как это можно сделать, как вариант сделать что-то типа счетчика отправок в динаме и если лимит достигнут, то лямбда должна подождать. Но это костыль) С concurrency у меня тоже не пошло, лямбды под нагрузкой троттлят и падают.

Как вариант, если лимит отправки во второй микросервис исчерпан, то можно сделать change_message_visibility у сообщения в sqs и выходить из лямбды. То есть сделать сообщение недоступным на какой-то интервал и когда оно вернётся заново попробовать его обработать.

А нельзя написать старый добрый сервис на условном ec2/ecs который будет обрабатывать очередь с комфортной скоростью?