I'm going to describe a very trivial example and of course in reality it is much more complicated.
In this picture I have an API gateway that some application will call to ask to get a list of animals. I have an "Animals" microservice that will handle the incoming request and then delegate the request to other microservices for each animal; I'm equating this to polymorphism.
When I first launch my application I only have "Dogs" and "Cats" available. At some point in the future I now have the ability to add "Rabbits" to my list of animals.
Questions:
You've got a couple of patterns going on here. The use of an API Gateway to abstract the underlying microservices is best described by as an API Facade. The dynamic capabilities of discovering new "derived" services (i.e. your Dogs, Cats, and Rabbits services) seems to fit with a Service Discovery Pattern.
The Service Discovery Pattern makes use of a Service Registry to make it known what services are available (which would enable your "Animals" service to get a complete list of animals)
In terms of how the "Animals" microservice should communicate to the derived services, really depends on the needs of the system. There are benefits and tradeoffs of using either. For simplicity, I would recommend HTTP will be the most straight forward and you have the choice to process requests synchronously or asynchronously. Using a message bus could be more complicated to process requests synchronously. If you expect a lot of volume in requests then a message bus could benefit, but beware of the complexity involved.