Небольшая задачка по #aws #serverless #telegram_bot

Есть тг бот, работает на AWS Lambda. Приветствует входящих пользователей. Вопрос - как сделать так, чтобы бот через час удалял за собой это сообщение? Условие : serverless решение. В рамках AWS.

Цель : нет нагрузки -> нет трат. Собственно, в этом же и есть преимущество serverless идеологии.

Первое, конечно же что приходит на ум - деплойнуть банальный воркер на минимальный EC2, который будет имитировать простейший scheduler. Может быть cron, может быть простой скрипт зацикленный, который будет ожидать "задания" в виде {messageId}, который нужно удалить в {dateTime}. Но... не хотелось без постоянно поднятой машинки.

Дальше приходит на ум амазоновская очередь SQS. Закидываем в очередь сообщение, ставим ей какой-то readyToHandle в 60 минут. Он через час становится видимым и подписываем на очередь еще одну лямбду, которая автоматически триггернется как только сообщение станет видимо в очереди.
Подходит, но есть одно но - SQS и правда имеет параметр сообщения "DelaySeconds", однако, его максимальное значение - 15 минут. Не подходит.

Вот в целом-то и все доступные варианты, если глянуть поверхностно. Но к счастью, есть ещё один...

Решение

Оказалось, на aws есть сервис States - AWS Step Functions. Машина состояний. Что это такое?

Step Functions — это сервис бессерверной оркестровки, который позволяет комбинировать функции AWS Lambda и другие сервисы AWS для создания критически важных для бизнеса приложений. С помощью графической консоли Step Functions вы видите рабочий процесс своего приложения как серию управляемых событиями шагов. Step Functions основана на конечных автоматах и задачах. Конечный автомат — это рабочий процесс. Задача — это состояние в рабочем процессе, которое представляет собой единицу работы, которую выполняет другой сервис AWS. Каждый шаг рабочего процесса — это состояние (с) habr

Если проще - вы можете "накидать" так называемых шагов на амазоновский юайчик, связать их стрелочками-условиями и быть уверенным, что они исполнятся при определенных условиях. Получается блок-схема. У кого есть айтишное образование точно рисовали такие на парах.

Одним из "степов" может выступать кубик с названием "Wait", который отвечает за "паузу в n ms". Выглядит это вот так. И этот wait time можно в том числе указывать и прграммно. Т.е. данные могут переходить по этим состояниям.

Собственно...подходит! Флоу получился такой :

1. Входит новый пользователь. Лямбда ловит вебхук от телеграма, приветствует пользователя.
2. Лямбда триггерит созданную стейт-машину, передаёт туда условный {messageId} сообщения, которое нужно удалить и время, через сколько секунд.
3. Запускается стейт-машина/флоу на aws. Она переходит в режим ожидания. А через час вызывает мою лямбду, передавая ей мой джсончик с данными.
4. Отдельная лямбда, выполняющая только одну функцию - удаление из тг чата... удаляет сообщение.

PROFIT!

Стоит это всё копейки, при минимальной нагрузке. Что-то а-ля 1000 переходов состояний за 0.025$ + копеечка за лямбду.

Может кому когда понадобится 😉
Если вдруг у вас есть другие workarounds - пишите в комментариях, интересно будет почитать