-
Notifications
You must be signed in to change notification settings - Fork 23
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add ADR for porting router and router-api to PostgreSQL
- Loading branch information
Showing
1 changed file
with
47 additions
and
0 deletions.
There are no files selected for viewing
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
# ADR 001 - How we migrate Router/Router-API from Mongo to Postgres | ||
|
||
## Context | ||
|
||
We need to migrate router (and [router-api](https://github.com/alphagov/router-api)) off of MongoDB as its datastore. The majority of GOV.UK platform is on PosgreSQL and there is no longer a strong enough case for being on MongoDB for router data. | ||
|
||
Even the [content-store is migrating from MongoDB to PostgreSQL](https://github.com/alphagov/govuk-rfcs/pull/158). | ||
|
||
This ADR is to outline our decisions and rationale on the steps we take for that migration: | ||
|
||
### The outline | ||
* Spin up a completely separate stack of router and router-api (govuk-docker first) that will talk to a PostgreSQL db only (as forks) | ||
* Provision in EKS a new PostgreSQL db | ||
* Provision the new p-router/p-router-api apps | ||
* Amend messages to router-api to be duplicated to p-router-api within content-store | ||
|
||
### Benefits of doing it this way | ||
* As updates are being made to the two databases, we can backfill data previous to that point in time without loss of service or downtime to the live (old) service | ||
* We can test traffic going to the new p-router stack insolation | ||
* Switchover would mean a change in DNS | ||
* We can rename p-router once we decommission old router | ||
|
||
### Risks | ||
|
||
* We never rename p-router | ||
* DNS messes up and caching gets in the way, causing downtime to requests trying to reach origin | ||
|
||
## Alternatives | ||
|
||
* We update router and router-api and deploy the changes to the existing version | ||
|
||
### Risks | ||
|
||
* Big bang | ||
* Running 2 databases under 1 app | ||
* Double code/logic to handle that | ||
* Harder to clean up | ||
|
||
## Decision | ||
|
||
* https://trello.com/c/nQcpWnD5/1788-provision-new-apps-in-govuk-docker-for-prouter-and-prouter-api | ||
* https://trello.com/c/dOXADTQP/1802-spin-up-a-separate-stack-of-router-api-l | ||
* https://trello.com/c/YJro3BGj/1790-spin-up-a-separate-stack-of-router-l | ||
|
||
## Status | ||
|
||
Accepted |