The internal implementation of the Apigee X runtime (pods, namespaces, etc) is not a documented part of the Apigee X product. We don't say "this is how it is implemented internally", and of course the ops/eng team may choose to change the implementation at any time.
But we do say that environments scale elastically. A proxy gets deployed to an environment, and if you ramp up load on that proxy, then there will be more cloud resources dedicated to handling that load.
It will be great if I can get some baseline numbers which can be supported by single Instance and how different APIs will be handled.
As stated previously, you can handle tens or hundreds of thousands of transactions per second easily. If you want millions, it may require some special configuration, and we'd like to talk to you about that. If you want to understand "a baseline" then you are welcome to conduct your own performance evaluation by sending lots and lots of concurrent requests into your Apigee instance, and measuring what you observe.
Trying to understand how should I segregate APIs having highest load.
Probably, you need not worry about this. Are you actively experiencing a performance obstacle? If not, I'd say, don't worry about it. You do not need to segregate your APIs. Just configure them and load them. Apigee takes care of the rest. It's a managed service. You don't need to manage the resources, and you don't need to concern yourself with how Apigee manages the resources. The resources are just available to you. There's an SLA and it's not bounded by transaction rate.
There ARE things you should concern yourself with, when considering performance: locality of the systems participating in the distributed transaction, size of payload, latency of the upstream (backend) system, network capacity. Those are all under your control. In my decade of experience, I observe that those factors are much more important in determining the practical performance characteristics of your managed Apigee proxies.
LinkedIn
Twitter
