There are very few absolute best practices and most practices are highly contextual, but here are some aspects to consider :
- Explore if differentiating pure internal traffic (operating in the intranet) vs external traffic (traffic coming from the internet) is helpful. Configure internal traffic to bypass some non functional policies(such as threat protection) . The overhead/latency Apigee adds on your traffic is upto you.You can implement this distinction in many ways(hint: Separate question)
- Expose AMQP/Rabbit MQ Brokers over HTTP. This simplifies client adoption of Async behavior - clients do not have to bind to AMQP/Rabbit MQ Clients, they can bind to HTTP
- Financial considerations aside, I always prefer to route all the traffic through Apigee. Having a single gateway for internal and external API's is really useful (for many reasons). But sometimes, it may be an uphill task to keep financial considerations aside.
- Despite the flavor of Event Driven Architecture you choose, expose your integrations as HTTP endpoints and route them through Apigee.
- If and when Apigee adopts HTTP/2, GRPC with protobuf, the latency of API's should begin to reduce even further
- Don't overthink latency, or if you are thinking latency , run a performance test with and without Apigee in the stack. Look at the difference of your numbers and determine if it's worth bypassing/ignoring Apigee Edge.
Apigee Edge is an API Gateway, modeling your platform interactions over HTTP is highly recommended.