SPIKE: how to move off of production db

[lauraGgit]

User story

As a user, I would like to not have my information manipulated, so that I can trust login.gov.

Notes

What is the value to the user in this story?

• following least privilege for our analytics
• read only
• increasing stability of production

What are things we should consider when making this story

Acceptance Criteria

• [ ] is determine a strategy to mitigate that
• [ ] shouldn't be possible write to production db for analytics query
• [ ] minimal performance implications of the prod app
• [ ] not raising concerns to devops folks about long running queries

[MacHu-GWU]

Available Solution:

• Add one more replica and make IDP app not first reading / writing from it. Since RDS use eventually consistency strategy, Data could be up to seconds / minutes of behind.
• Take snapshot periodically (every day) and make a clone database. Data could be up to 1 day behind.

@lauraGgit the DB is more about Devops work (I think the DBA is part of our Devops team), we need a meeting with Devops.

[lauraGgit]

@MacHu-GWU can you say a bit more about what you mean about "*DP app not first reading / writing from it"?

[MacHu-GWU]

@lauraGgit, Separate Read / Write is a common strategy to balance the workload. For example a db cluster usually have 3 notes a, b, c. We assume that for write (app try with node a first, if failed then try node ), and for read, for redundant. When there is a write operation, it goes to , and new data is eventually available (see the AWS RDS internal implementation doc) from , then .

My point is, analytics may query from (with data delay), but App prefer read from than .