The heat death of the universe!
The problem here is not just Twitch resending an event, but an attacker obtaining a valid payload/set of headers and spamming them at your server. Which is the true nature of a replay attack
This depends on the topic, the data being consmed and what you are doing with the data.
Like if you get a duplicate stream up/online for a stream you thought was already up then you do a check against the stream cache in your DB rather than a message ID compare for example. Similar for the subscription data. Can’t become a sub twice on the new sub feed within 28 days ish (weird math not persisting)
So in summary: do what works best for your application, the data it consumes from Twitch and what it does with it.
You might in fact not need to dedupe by ID at all in some cases. Theres a number of “what ifs” involved depending on what you do really.
Generally most of us run a rolling cache and sit on them for 24 hours or so. But I don’t apply this rule to certain topics due to the nature of the data meaning a replay occuring is irrelevant to my application and it’s state.