There is no one size fits all answer here.
Right now, I'm finding a bit too many if else cases with my implementation, thinking if there's a better way to do this.
On the spectrum of good to bad for your specific needs, tenanted microservices are on the better end of the spectrum than hardcoded if/else chains, but there are many things inbetween that you have skipped over.
It sounds like you're struggling to properly separate your specific tenant logic, and are trying to put the microservice boundary there to strongly enforce it. That's not necessarily wrong, but it is disproportionate overkill. It's the equivalent of enforcing that you wake up on time on the morning, and getting an industrial fog horn to wake you up.
Just like how much more reasonable alarm clocks exist for a lower price, the same kind of code separation can be achieved with self-discipline and clean coding practices in the same codebase, which costs less overhead than taking the microservice route.
Now, what I want to do is have one microservice per tenant that will convert the data into a common schema on which I'm going to do further processing and push to my DB.
The main issue here, as far as I am concerned, is that you're trying to have multiple microservices access the same database (and by the sound of it, the same tables).
That's a big red flag I suggest staying away from. Either you:
- Commit to the microservice architecture and make a "common schema" microservice, which does the "further processing" and db access, and which all the tenanted microservices rely on; or
- Stay away from microservices and properly separate your code a different way.
The processing logic for each tenant is slightly different from each other
A big question here is how sizeable that logic is. Based on your (admittedly vague) description, it sounds like some minor mapping logic rather than a completely redesigned business layer.
The smaller the size of the changed logic, the less justification there is for hosting separate microservices for this logic.
It doesn't sound like microservices are the right way to go about this. You're not really getting the benefit of independent life cycles since you're relying on a shared database, and shared common schema processing logic.
Instead, I suggest you look are restructuring your codebase in order to cleanly separate the interface (common schema) from the implementations (tenanted logic), so that your distinct implementations can be orchestrated by a specific dependency graph as opposed to if/else chains.