Devo sostituire la classe "table" di SQLAlchemy (dichiarativa) con un wrapper per lo più funzionalmente equivalente, che utilizzerà l'API di un altro microservizio. Tutti gli usi possono essere modificati, quindi non è necessario eseguire il mimetismo completo delle funzionalità di SQLAlchemy, ma con il reimplementing sto perdendo alcune cose utili come il caching intelligente, il pooling delle connessioni (modo asincrono), il supporto delle transazioni.
La classe "table" non è solo la dichiarazione dei campi della tabella, ma contiene anche alcuni metodi helper di livello superiore, un metodo di business logic uniforme.
Supponendo che il supporto delle transazioni non sia un problema nel caso, quale sarebbe il buon approccio (i) per gestire il caching?
Il mio approccio sarebbe ignorare completamente la memorizzazione nella cache, ma ho bisogno di essere preparato per ottimizzare.
La soluzione può ancora utilizzare il database relazionale disponibile, se aiuta, comprendendo che l'autorevole fonte di dati per l'entità in questione è altrove. Introducing memcached o it's ilk è il secondo migliore.
Ci si aspetta che una chiamata API remota abbia un po 'più di latenza della chiamata RDBMS locale, ma fortunatamente non ci si aspetta che le operazioni siano massicce, non ci saranno "join" poiché la tabella in questione ha solo un posto riferito da chiave esterna (e che sarà facilmente risolto)