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).
First, I think it would be good to find a way to measure how important caching would be.
Once you’ve determined that you absolutely need caching, I guess a relational database would be better than using something like memcached, as you can have a very sizable cache without using too much memory. You may want to consider Redis with its persistence support enabled as well.
Make sure you treat cache invalidation with care, as you probably don’t want to return obsolete information from the cache.
Optionally, though, maybe you could decouple your code a bit, by separating the business logic from the database model. Perhaps you could have your domain model class, and a helper class that would fetch it from a persistent location, such as the remote API(with or without caching enabled), or from the current SQLAlchemy-based solution. That way, in the future, you could add/replace yet another persistence mechanism without too much trouble or having to comply to a third-party interface, like SQLAlchemy’s.
2