In case
1. some recommendation scenario is not depending on current user
2. site has very high traffic

it makes sense to add some caching layer to the get-recos calls, currently executed via ezjscore/call/getrecommendations::$nodeid::$scenario::$etc..

This would be a breeze if the structure of the urls was adjusted just a wee bit to

ezjscore/call/getrecommendations::$scenario::$nodeid::$etc..

this would allow the usage of setting
site.ini / HTTPHeaderSettings / HeaderList
to add some cache-expiry header to recommendations givven for a specific scenario but not others

it would then be possible to extend ezreco extension to receive "scenario has been updated" calls from the yoochoose servers, and transform them in appropriate PURGE/BAN requests for Varnish, in case varnish is used

in case a node is edited, code would have to loop over all existing scenarios and call PURGE once for each scenario which is cached. This could be a quick, fast loop so there is little penalty for that

all in all: the recommendation is to switch the url structure used for getting recos via ezjscore