Strategies for ensuring NodeNorm remains continuously online for Translator

[gaurav]

• Have multiple NodeNorm instances (e.g. Prod A, Prod B and Prod C) behind a distribution server -- that way, we could take down Prod B, load it with new data, then take down Prod A and do the same thing, and the net result would be zero downtime. (https://github.com/TranslatorSRI/NodeNormalization/issues/174)
  • While we have had bugs with NodeNorm as a web frontend, the real issue here is in Redis -- if we could swap Redis instances or keep the Redis cluster set up such that it can hold different versions of NodeNorm simultaneously or maintain a redundant Redis cluster we could plug in if needed, that could help with most of the remaining issue.
• Other ideas?

[gaurav]

One of the main reasons why every KP can't "host their own NodeNorm" is because NodeNorm is so darn big. If the proposed plan to collect every possible node identifier across the Translator system happens, we could use that information to dramatically reduce the size of NodeNorm, possibly making it small enough for ARS/ARAs/KPs to host their own local version of NodeNorm.