I have to replace SQLAlchemy "table" (declarative) class with mostly functionally equivalent wrapper, which will use API of another microservice. All the usages can be edited, so there is no need to do complete mimicry of the SQLAlchemy features, but with reimplementing I am loosing some useful things like smart caching, connection pooling (async way), transaction support.
The "table" class is not just declaration of table fields, but also contains some higher level helper methods, an even business logic methods.
Assuming transaction support is not an issue in the case, what would be good approach(es) to deal with caching?
My approach would be to ignore caching completely, but I need to be prepared to optimize.
Solution can still use the available relational database, if it helps, with understanding that the authoritative data source for the entity in question is elsewhere. Introducing memcached or it's ilk is the second best.
It is expected a remote API call would have a bit more latency than local RDBMS call, but luckily operations are not expected to be massive, no there will be "joins" as table in question has only one place referred by foreign key (and that will be easily worked around).