undefined | Better HN

story

0 pointssneak5y ago0 comments

> Personally I prefer to have explicit control over the caching mechanism rather than leaving it to network elements or browser caching.

I'm not talking about browser caching, I'm talking about the reverse proxy that fronts your ("backend") service to the internet. High traffic global/unauthenticated reads, especially those that never change, should get cached by the frontend (of the "backend", not the SPA) reverse proxy and not tie up appservers. (In our case, app servers were extremely fat, slow, and ridiculously slow to scale up.)

0 comments

throwaway4good5y ago

I am sure you have good reasons for your concrete design but in the general case: Why not simply build the caching into your backend services rather than having a proxy do it based on the specifics of http protocol? It would be simpler and far more powerful.

sneakOP5y ago

Because the backend app servers were extremely fat (memory and disk intensive) and every request they served that could have been served from an upstream cache was a request that they weren't serving that actually required all of their resources to serve.

Caching upstream on (vastly cheaper) instances permitted a huge cost savings for the same requests/sec.

mkranjec5y ago

Proxy caching / leveraging caching to external service makes sense when you have a LOT of users scattered around the globe - let Akamai/Cloudflare take care of edge node caching and maintenance. In the end it saves you a lot of engineering time and infrastructure costs not mentioning user experience. YMMV but it pays off in our current setup.

tatersolid5y ago

Because if you use HTTP caching, you can use a CDN with 100s of global locations. Which is quite a bit more powerful than any custom solution.

j / k navigate · click thread line to collapse