Kérdés, hogy mennyire valós idő az a valós idő, a config management cuccok valóban általában pár perc lauffal működnek (ami bele szokott férni), viszont az összes ilyen "meg kell néznem hogy tényleg..." izét megoldják. Tipikusan úgy működnek, hogy amíg látszik a kezelt node, addig kikényszerítik, hogy az legyen a konfig, ami nekik szerintük kell. Ha elbabrálták visszateszik.
Az elosztott konfig adatbázis szintén járható út, ha olyan az appod, itt viszont az SQL a bazi nagy overhead. És szinte biztos vagyok benne, hogy nincs rá szükséged, mert valami SELECT * from config where node = énvagyok típusú tök atomi izék vannak, tipikusan key-value párok a konfigok. Erre egy bármilyen lightweightebb adatbázis jobb megoldást ad, mert lesz robosztusan működö szinkron.
Egyébként csatlakoznék kollégához: most, hogy elkezdtél gondolkodni, rájöttél, hogy tulajdonképp elég egy írható db. Még pár (tíz / száz) iteráció, és végiggondolsz mindent, ami egy konfig management eszközhöz kell :) Szóval inkább ismerkedj ezekkel, mert jók szoktak lenni. Vagy ha nem, akkor mesélj már egy kicsit bővebben arról, hogy tulajdonképpen mit akarsz megoldani, milyen elvárások és constraintek mellett (pl azért ragaszkodunk-e az sqlhez, mert szög-kalapács, vagy azért, mert a végén a programnak mindenféleképp abban kell a konfigja)