Change Details

Based on a recent multi DC strategy meeting ([notes - NDA restricted](https://docs.google.com/document/d/16C9KNA8rlvC2fzQNQai3k-j77qgQdQ4zu2QdSV9Vz4s/edit#)), it was brought up that the DBAs may want to change the previous strategy set out for ParserCache DB. The status quo is that they are replicated in a bi-directional nature where writes can happen in either DC and the dataset may or may not be eventually consistent. (The typical multi-master concerns don't apply since there only simple key-value operations on these tables using a primary key, and the primary key is a predetermined string, not an auto increment.) These loose guruantees are acceptable since the values are verified by MW at runtime and discarded accordingly, so it's totally fine for an older "wrong" write to win some race. I believe this bi directional replication was set up specifically to aid in switch overs and to support multi DC, but I could be wrong, maybe it was set up this way for another reason? The concerned raised by @Kormat is that the current set up causes lag spikes, with the question whether we actually need this or whether a locally kept cache would suffice.

//Split out from {T133523}// Based on a recent multi DC strategy meeting ([notes - NDA restricted](https://docs.google.com/document/d/16C9KNA8rlvC2fzQNQai3k-j77qgQdQ4zu2QdSV9Vz4s/edit#)), it was brought up that the DBAs may want to change the previous strategy set out for ParserCache DB. The status quo is that they are replicated in a bi-directional nature where writes can happen in either DC and the dataset may or may not be eventually consistent. (The typical multi-master concerns don't apply since there only simple key-value operations on these tables using a primary key, and the primary key is a predetermined string, not an auto increment.) These loose guruantees are acceptable since the values are verified by MW at runtime and discarded accordingly, so it's totally fine for an older "wrong" write to win some race. I believe this bi directional replication was set up specifically to aid in switch overs and to support multi DC, but I could be wrong, maybe it was set up this way for another reason? The concerned raised by @Kormat is that the current set up causes lag spikes, with the question whether we actually need this or whether a locally kept cache would suffice.

//Split out from {T133523}// Based on a recent multi DC strategy meeting ([notes - NDA restricted](https://docs.google.com/document/d/16C9KNA8rlvC2fzQNQai3k-j77qgQdQ4zu2QdSV9Vz4s/edit#)), it was brought up that the DBAs may want to change the previous strategy set out for ParserCache DB. The status quo is that they are replicated in a bi-directional nature where writes can happen in either DC and the dataset may or may not be eventually consistent. (The typical multi-master concerns don't apply since there only simple key-value operations on these tables using a primary key, and the primary key is a predetermined string, not an auto increment.) These loose guruantees are acceptable since the values are verified by MW at runtime and discarded accordingly, so it's totally fine for an older "wrong" write to win some race. I believe this bi directional replication was set up specifically to aid in switch overs and to support multi DC, but I could be wrong, maybe it was set up this way for another reason? The concerned raised by @Kormat is that the current set up causes lag spikes, with the question whether we actually need this or whether a locally kept cache would suffice.