VAR reversals: Add global secondary index to live activities payload table#1856
Open
vlbee wants to merge 1 commit into
Open
VAR reversals: Add global secondary index to live activities payload table#1856vlbee wants to merge 1 commit into
vlbee wants to merge 1 commit into
Conversation
* primary key match id and sort key by ttl to allow us to easily find the most recent payload sent for a given match id.
vlbee
changed the title
4 tasks
vlbee
marked this pull request as ready for review
July 21, 2026 09:45
8 tasks
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Followed by #1857
What does this change?
Adds a Global Secondary Index to the live activities payload table
ttl = (System.currentTimeMillis() / 1000) + (14 * 24 * 3600)This PR needs to be deployed in isolation for the creation of the GSI.
The live activities Payload table is billed on demand, so AWS will handle capacity when the GSI first rolled out. Subsequent writes to the main table will also update the GSI simultaneously.
I don't think it is strictly neccessary to check the notifications payload table and diff in two places - if we decided we need a GSI on the push notifications table, this is provisioned so either A/ needs to be converted to on demand or B/ provisioned capacity reviewed as writing to GSI consumes write units. The initial creation of the GSI may also require a temp increase in provisioned capacity.
Both tables a relatively small so it should be safe to use
Projection.ALLon the GSI*mobile-notifications-liveactivities-PROD - 79 items - Table size 28.4 kilobytes
*mobile-notifications-football-notifications-PROD - 784 items - Table size 1 megabyte
Why?
Introduction of VAR in football matches means key events such as a goal or red card can be reversed. This is not captured in the incoming PA data; the overruled event simply disappears from the match event timeline. In practice this means LiveActivities and updated Android push notifications display the wrong score until a subsequent "triggering event" emits a new update.
We plan to diff the incoming football data and insert a
state-changesynthetic event to trigger an update to capture these otherwise invisible changes.How has this change been tested?
Deployed to CODE, new index built as expected.
Index is queriable via the AWS console.
How can we measure success?
Have we considered potential risks?
Images
Accessibility