3scale apicast is designed as a heavy/central api gateway. We can identify a few downsides when using a heavy api gateway in a microservice architecture.

Scalability: The api gateway does not scale with the microservice itself.

Availability: The api gateway is centralized component which acts as a single api entry point for the clients. The outage of the api gateway or its control plan brings down all apis on this instance and affect all clients

Resources: The api gateway needs a lot of computing power and must handle a lot of network traffic. The resources must be available to handle various api traffic patterns at unknown day times

East-West Traffic: Intra application communication between microservices over a central api gateway brings back the monolith. The traffic volume can get really high and latency is key.

An idea to address this problems could be to introduce a microgateway which can be deployed with each microservice (e.g sidecar container). With this, each microservice has its own lightweight api gateway which scales with the service. An outage of the microservice has limited impact on the clients. This gateway only has to process the load of the service and can be fine tuned based to the need of the microservice. It should also be decoupled from the control plan as much as possible by default, to prevent the control plane as the single point of failure. This does not mean microgateway will replace the api gateway. For example north-south traffic can still be processed by the edge api-gateway but east-west traffic is directly managed over the microgateway.