i was in the process of writing a snarky reply describing how the next level enterprise approach is to host api/product in microservice A and api/options in mic

i was in the process of writing a snarky reply describing how the next level enterprise approach is to host api/product in microservice A and api/options in microservice B, each with their own internal data store using completely different tech stacks. but, if you've already suffered through the pain of attempting to implement some kind of best-effort ad-hoc distributed commit logic in your client code, then needing to call two completely different services for api/product and api/options doesn't really make anything _worse_. on another hand, it doesn't make anything better.