When syncing the configs to each region, it would be good to be able to track which regions we successfully produced to, so that if we have to retry we only retry failed regions.
At the moment UptimeSubscription is used to keep track of the config for the uptime checkers, as well as the state of whether the subscription has been successfully created.
It might make sense to split out the subscription piece from the configuration. So we’d have a subscription per region. So that the timings end up the same, we’d keep the subscription_id on UptimeSubscription, and just move the subscription sync state code to an UptimeSubscriptionRegion table.
New table: UptimeSubscriptionRegion
id
status (active/creating/updating/deleting/disabled)
uptime_subscription_id
region_id (or if from config, region_slug)
New table: Region. Or should this just be a hard coded list of regions, or from config?
id
slug?
Changes: UptimeSubscription
Remove status
Since UptimeSubscription can feed into one or more ProjectUptimeSubscription rows we will also need a way to differentiate which region each of these is associated with. Alternatively, we can remove the uniqueness constraints on UptimeSubscription and handle attacks against specific domains via other checks when creating subscriptions. If we do this, possibly we even end up consolidating the tables together.
See https://www.notion.so/sentry/Uptime-Path-to-Multi-Region-1478b10e4b5d80738ed1f95b9a13dbf7?pvs=4#14a8b10e4b5d8013966cde73115533e9 for an overview.
When syncing the configs to each region, it would be good to be able to track which regions we successfully produced to, so that if we have to retry we only retry failed regions.
At the moment
UptimeSubscriptionis used to keep track of the config for the uptime checkers, as well as the state of whether the subscription has been successfully created.It might make sense to split out the subscription piece from the configuration. So we’d have a subscription per region. So that the timings end up the same, we’d keep the
subscription_idonUptimeSubscription, and just move the subscription sync state code to anUptimeSubscriptionRegiontable.New table:
UptimeSubscriptionRegionidstatus(active/creating/updating/deleting/disabled)uptime_subscription_idregion_id(or if from config,region_slug)New table:
Region. Or should this just be a hard coded list of regions, or from config?idslug?Changes:
UptimeSubscriptionstatusSince
UptimeSubscriptioncan feed into one or moreProjectUptimeSubscriptionrows we will also need a way to differentiate which region each of these is associated with. Alternatively, we can remove the uniqueness constraints onUptimeSubscriptionand handle attacks against specific domains via other checks when creating subscriptions. If we do this, possibly we even end up consolidating the tables together.