When we first started integrating with third parties, we built an OAuth provider using the Doorkeeper gem. For convenience we have it mounted as a Rails engine on our marketing site. It shares the marketing site’s main database and stores information in three tables: oauth_applications, oauth_access_grants and oauth_tokens.
Now that we want to use OAuth for more high-volume needs, it’s no longer appropriate for our OAuth needs to be serviced by themarketing-site.
The overall plan is to deploy a standalone Rails application that serves as the OAuth provider, and instead of storing tokens in the marketing-site DB, we will store them in a standalone DB that is private to this app.
This is fast and relatively low-risk; we are continuing to use the exact same OAuth provider logic we have been using for years now; we’re just moving it to a new home. By having this handled by separate infrastructure we can have this app handle heavy traffic without driving extra load to marketing-site.
To roll this out successfully we will deploy this in phases.
Pre-Deploy Steps
Phase 1
The DBA will configure a database replica for marketing-site which will populate with all of marketing-site’s data.
Engineers will finish building the standalone OAuth app extracted from the marketing site, and the Devops team will prepare the infrastructure
Deploy Steps
Phase 2
Deploy the OAuth standalone application, pointing it to users database and the current marketing-site master database for that environment.
Test this app by sending requests to it and verify that the full suite of OAuth requests can be made to it.
Phase 3
Update marketing-site’s nginx rules so that traffic to /oauth/* is proxied to the new standalone OAuth app. At this point, marketing-site’s OAuth code is unused and assuming this step is successful, can be removed.
OAuth tokens are still being stored in marketing-site’s primary database, but they are being replicated to the replica that will become the primary database for the standalone OAuth app.
Phase 4
The marketing-site replica database will be un-linked from the primary and will be promoted to become a primary itself.
the standalone OAuth app will receive updated config cars to point to the newly promoted database and will be restarted.
Phase 5
Drop all the other tables out of the Oauth app’s database, leaving only oauth_applications, oauth_access_grants and oauth_tokens. Spin up replica databases.
Load test needs
When we push out new client apps that use OAuth in place of the legacy API tokens, each client will start sending requests to the OAuth server to get an auth token and we need to monitor how well the standalone app can handle the traffic.
iOS and Android both offer phased releases so we avoid getting overwhelmed with requests from 100% of users right after the update. We should absolutely use this feature for the app releases that start using OAuth.
Background
Pre-Deploy Steps
Phase 1
Deploy Steps
Phase 2
Phase 3
Phase 4
Phase 5
Load test needs