Update replay considerations #4253
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update replay considerations to take into account realtime events as well as a margin for retries. If you're also sending data to the destination being replayed to in realtime, then when determining your replay's limit you'll want to take into account the rate limit being used by realtime events, and you'll want to also account for a small margin of your rate limit to allow events to be retried.
pwseg
approved these changes
Apr 11, 2023
pwseg
added
the
content-update
|
Thank you for your contribution! Your pull request is merged, but may take a day or two to appear on the site. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update replay considerations to take into account realtime events as well as a margin for retries.
If you're also sending data to the destination being replayed to in realtime, then when determining your replay's limit you'll want to take into account the rate limit being used by realtime events, and you'll want to also account for a small margin of your rate limit to allow events to be retried.
Proposed changes
It's good for both customers who are requesting replays and CSE's who'll be running the replays to take these additional parameters in mind when determining the replay limit. Clarifying the rate limit can be the difference of all realtime events failing due to there being no margin for retries, as the replay could be taking up the entire allotted rate limit.
Merge timing
Related issues (optional)
n/a