This implementation depends on the bot having successfully posted a reply to the user. The name of the CloudWatch rule is stored in Redis, with the ID of the bot's reply as the key. If the user replies "cancel" to the message, the bot will look up the tweet and cancel the associated rule. Alternatively, the Redis entry will expire when the reminder expires.
I know this implementation is tied to a successful reply, but I don't anticipate such high usage as for this_vid. If I need to, I'll rework it later. The key difficulty is storing state across tweets (a "cancel" tweet contains only information about itself; other than the reply ID, there's no direct way to find out the referenced reminder) while optimising speed by minimizing requests and batching as many requests as possible.
This implementation depends on the bot having successfully posted a reply to the user. The name of the CloudWatch rule is stored in Redis, with the ID of the bot's reply as the key. If the user replies "cancel" to the message, the bot will look up the tweet and cancel the associated rule. Alternatively, the Redis entry will expire when the reminder expires.
I know this implementation is tied to a successful reply, but I don't anticipate such high usage as for this_vid. If I need to, I'll rework it later. The key difficulty is storing state across tweets (a "cancel" tweet contains only information about itself; other than the reply ID, there's no direct way to find out the referenced reminder) while optimising speed by minimizing requests and batching as many requests as possible.