How is it the MVC framework's fault that aggregating data from third parties is expensive? Lazy evaluation will help to some degree, as will caching data local

How is it the MVC framework's fault that aggregating data from third parties is expensive? Lazy evaluation will help to some degree, as will caching data locally once you've retrieved it. Extending your ORM to invoke third party pay-per-view APIs is obviously the wrong way to solve this problem. That does not mean that MVC or ORM are obviously the wrong way to solve this problem. MVC will help you with the stuff that it is suited to, as will ORM. Neither are suited to optimising usage of expensive pay-per-view APIs. You need to build the API interaction part separately, and arrange for the MVC side of things to work with thst API-using-API. Off the cuff, why not have a batching task that takes requests from the last fraction of a second and sends them off to each provider? How long can you stretch that fraction of a second without upsetting you customers? Are they willing to wait three seconds? If you get a dozen requests per minute, three seconds might halve your API bills. As you said, MVC breaks when you do not control the data. So your job is to get the data into a form and place that you control.