Support `IDistributedCache` (or similar mechanism) for proxy config invalidation instead of relying only on `IChangeToken`

[gumbarros]

Currently, YARP relies on IChangeToken to detect and propagate configuration changes for proxy routes and clusters. This works fine in a single-node setup, but in a distributed architecture it becomes a limitation.

For example:

• I have a WebAPI where I update proxy configuration dynamically.
• My MVC application (which uses YARP) runs in a separate process, or can be in another server
• Since YARP only listens for IChangeToken changes, the MVC app never learns about the configuration updates that happened in the WebAPI process.

This makes it impossible to reflect configuration changes across distributed apps without reloading or manually syncing configurations.

Proposal:
Add support for IDistributedCache (or a pluggable distributed store abstraction) as a configuration source for YARP. That way:

• Updating configuration in one app (e.g., via WebAPI) would write to the distributed cache.
• Other apps using YARP would read from the same distributed source and automatically reflect the configuration changes.

This would enable YARP to be used seamlessly in distributed architectures without needing custom synchronization layers.

Example Scenario:

• WebAPI updates the proxy routes in Redis (via IDistributedCache).
• MVC app using YARP picks up the new routes automatically without restart.

.NET 9 HybridCache is also a good alternative.

[lqlive]

In YARP, customizing the ConfigurationConfigProvider allows us to not be overly concerned with the storage problem.

However, from your description, it seems you want to store YARP's configuration in a database, use a WebAPI to operate on that database, and if the data in the database changes, synchronize it to YARP in real-time.

We can consider a few issues:

1.Relational Databases (MySQL, PostgreSQL, Oracle): These types of databases have their own mechanisms for data changes, which might not be uniform.

• We could use triggers for this, but that leads to high coupling; once a trigger in the database changes, the corresponding program also needs to be modified.
• Another way is to use a timer to poll the database. I believe KONG does something similar (I'm not entirely sure of the specific implementation; it might also use PostgreSQL's pub/sub mechanism, since KONG's configuration is stored in PostgreSQL).

2.Non-Relational Databases (Redis, MongoDB, ETCD): These databases have their own listening/notification mechanisms. In this case, we can rely on the database's native mechanism to detect data changes and then synchronize them to YARP.

Finally, I'd like to add that the IDistributedCache abstraction is still at the storage layer, which the·ConfigurationConfigProvider can already handle. If we use a database to manage configuration, I feel the focus should be more on how to distribute the configuration to different YARP nodes.

Here is my implementation using MongoDB to achieve configuration change distribution.
https://github.com/lqlive/sail/blob/main/src/Sail/Grpc/ClusterGrpcService.cs#L25
I hope this helps.