There are 3 ways I can see routes being defined for a proxy:
a) In config via a config file, changeable at runtime - this is what most proxies do today
b) Statically defined in code - setting up static endpoints similar to the sample startup.cs
c) Dynamically created by code. This seems to be what most of the Azure partners need. At startup, and periodically the code will need to query a backend to fetch both the Endpoints to listen to, and where each of those should be routed.
[added from discussion below]
d) When there are too many routes to load them all, we need to be able to query a database per request to load and cache routes. From our research, more Azure partners do this than C.

This last bucket is where we need to shine and differentiate ourselves from the competition.
It will need to account for:

• Listening on new IP Addresses / ports
• SNI and being able to dynamically lookup a cert based on the client hello
• route based on the hierarchy of the URI path & query string

For some apps, they may need to do a DB lookup to discover the cert/route based on the URL being passed - so will need to have a cache and fallback mechanism.

Performance would dictate you probably need optimized structures like a trie, that I suspect are behind the existing routing tables. Either we need APIs to be able to dynamically edit the tables, and/or create and replace the tables, or be able to use the same concepts from custom app code for the proxy.