I refer to the first proposal since the second option (re-start the instance) would clear all applications from the cache and not only the one that was deleted from persistency. It will lead to additional calls to persistency to re-build the cache.

RE central cache: as you correctly said à it is centralized, it means that:

1. for each request to the reverse proxy we need an additional hoop to the central cache.
2. We used NGINX for its reverse proxy and caching capabilities in a distributed architecture, we will lose this
3. We need an additional runtime dependency to the central cache = potential failure point

Imagine this flow:

1. API returns that 5 instances exist
2. While calling in a loop from instance 1 to instance 5, 2 new instances are created by CF

Question: will CF create the new 2 instances as index 6,7 (so they won’t be called) or they can be introduced in the middle (e.g.: moving the previous 4,5 to 6,7)?

> Was the current maximum number of instances really implemented?.
No, it wasn't implemented yet. But it's just an improvement to avoid calling the API.

> I see your point however it sounds like something that should be provided centrally.
The normal way to do this is to have a central cache (e.g. a redis/cassandra/memcache) and have your reverse proxy use it. Then when you want to flush it you call any instance and the instance clears the backing data store. This is arguably "safest" approach, but it has a big downside: it is centralized.

> Do you consider this as production API?
I don't know to which of my two proposals you are referring. I think both are fine, since they are both supported. We routinely use X-CF-INSTANCE-INDEX for monitoring/debugging purposes (it's provided for this very reason, and if you squint hard enough "clearing a cache" can actually be considered a debugging operation, since cache invalidation should ideally be handled automatically by the reverse proxy+backend application). And we routinely use the CF API (the one that would be exclusively used for my second proposal for restarting all instances) for controlling every single application.

> I had the impression that it is only used for development purposes.
I have the feeling you're mixing two concepts here. "Used by developers" (i.e. the users of the platform) is not the same as "used for development" (i.e. not for production). By this logic the CF API should only be used for development, not production... and that's clearly not the case. The CF API can be used for production, but only by developers.