eventsourced | building reliable , scalable and distributed event | Microservice library

I have been exploring Microservice Architecture, and even though the technologies I use are in Microsoft Domain, the question is generic.

I get the Idea of API Gateway esp for things like Authentication. The pattern I am roughly following is based on CQRS + Event Sourcing

Request-> Command ##CommandBus##->CommandHandler -> Change Aggregate State->Store Events-> PublishDomainEvents ->Publish Integration events ##Event Bus## -----> Update Read Models

Many times initial Command will be handled by ProcessManager (consumer) to Orchestrate workflow.

All Microservices Application Layer consume Command from Bus and work on changing Aggregate state. Once done, the Read model store is updated. Currently, there is only a single Read Database which is updated

When I started with Command Bus, The REST API per microservices were for mainly Get requests ( Read ), which would dip into the same Read Database as all other Services and rest for accepting Command from Gateway.

Based on my current Scenario, Is there a logic in having REST API's per Microservice? I know we can do Async with Rest API to push commands, but what is the point when I am already using a Bus.

But now I am thinking of not having API per Service but rather API's based on usage. It's then not limited to single Gateway but few Gateway API projects.

Are there any Cons/ pitfalls with this approach?

Edit 2-- **Trying to rephrase if it gives context ** My microservice structure is very similar (to what @mrdnk commented) . As you In I will introduce technology to make it more clear. I use Mass transit over RabbitMQ for inter service communication.

As of now I have API gateway used by client applications, which would then call appropriate microsservice API to push a command object. the API method itself acts as a Command Handler (acting as Application layer) calls Aggregate and make it undergo changes. Domain Events based on the change are published within the process with Mediatr. Any events that outside (microservice) world needs to know is published on the bus. I started to look at the communication and said to myself why not use the Bus also for commands (as command bus). That way I can have more reselient and async process.

Application layer will listen to command and handle appropriately. This way I feel the service is more encapsulated. On API side (individual microservce) I dont need to expose any rest api for use by gateway. API in Gateway wil listen to request and create command object. this will be queued to bus. Consumer (command handler) on Microservice will consume Command and so on.

Currently all Writes are eventsourced (mongodb). Reads go to SQL Server. I can create API just for Queries from Read side. No more need to have Http API from Microservice at all.

I know technically it would work but Dont know if there are any pitfalls.

Regards, Mar