In a microservice based multi-tenant web application, there are some cases of tenant specific logic where I am unclear about the proper strategy to handle them. Thank you for pointers.
These two cases I think I have a grasp on. They lie at opposite ends of a spectrum:
- logic that can be well abstracted. e.g. call to rule engine as part of the request pipeline. the rules are the data. strategy: make the logic into data associated with the tenant
- logic that is practically impossible to abstract. e.g. logic closely related to customers own interfaces. strategy: provide robust interface against which extensions can be built, consider extensions not part of the application
These two I am not sure about:
- microservices which actually have logic as data. e.g. trading algo platforms where each user builds their own python script trading algo to let it run against historical data or even realtime. The logic is definitely unique-forever to this tenant and might on top even be their IP. feels wrong to put the code into a database, so how is it persisted, isolated, executed, ...?
- CSS. It's not really logic, but probably does not belong in the database either. It feels wrong to just put a tenant specific folder into the webapp repository. Is it proper to manage css in a separate repo and treat it like a config (as in cac pattern)?