Don't you now have "microservices" bundled together in a single binary - and deployed together? If each of your component exposes different APIs and each instance only handles certain endpoints, then you kind of have microservices - not literally, but it seems the idea is the same.
Simplicity being a benefit, I don't really see how the dynamic traffic routing is a huge benefit vs microservices - you can dynamically scale up/down microservices too.
I am not saying this is a bad approach, by the way, but just that it isn't much different from microservices.
Microservices are only microservices if they have both narrow focus and radical independence. If they have narrow focus without the independence then you probably have a monolith with 25 executables to deploy.
Build a monolith which does everything. Deploy multiple instances. Route booking requests to a subset of the instances. Route other requests to the other instances.
We did this at an old job. We had a data-intensive app which had a web UI for users, an admin UI, and an API for data export. They all had lots of common code for persistence, querying, aggregation, etc. Because of the common code, the simplest way to implement the three interfaces was in a single codebase. But because API requests could sometimes crash the app (we didn't do a great job here!), we segregated the API into its own pool of instances. We didn't segregate the admin UI, but could have done that if necessary.
As well as simplicity, another advantage of this approach is that the decision about how to split up traffic is very dynamic: you can change it just by adding or removing instances and changing load balancer config, without having to make any code changes. if you split the traffic up into separate microservices, you have to make that decision upfront, and changing it is a lot of work.