How Syncing Works

Very much a work in progress…

  • your full history will be synchronized into CityStrides, there is no limit to the number of activities that will sync
  • there are limits in each service that may cause sync delays
  • the Status Page shows some detail on delays
  • an activity must first be synchronized into CityStrides, and then it can be processed for completed/progressed streets
  • post-sync activity processing has its own queues (which can be delayed; see Status Page Wiki)
  • MapMyFitness & Strava provide webhooks, so CityStrides is alerted of each activity after it is saved there
  • Runkeeper does not have webhooks, so each sync is a full account sync.

Sync Prioritization

This is a best effort prioritization of how activities are brought into CityStrides. Given the low API limits from Strava, it’s most applicable to users of that service. For other services, there’s a general prioritization placed on subscribers.

  • New activities for subscriber accounts
  • New activities for regular accounts
  • Historic activities for subscriber accounts
  • Historic activities for regular accounts

Activity Processing Prioritization

This is how the system weights the different queues. It works through a queue in its entirety before moving onto the next queue. This is all specifically for street progress/completion.

  • Subscribers
  • New users
  • Regular users

Strava-specific

  • Strava’s API limits for requests are 600 every 15 minutes & 30,000 every 24 hours (resetting at midnight UTC)
  • I have to self-limit down to 300 every 15 minutes so that syncing can operate 24hrs
  • Full history syncing is done by collecting all of the historic activities (this ‘costs’ 1 API request per 100 activities) and then queuing each individually (each individual sync ‘costs’ 1 API request)
3 Likes