Decide how extensively to cache requests

[canonical]

Decide how extensively to cache requests

[cprov]

@nottrobin any solution involving per-unit caching will stop working the moment you deploy multiple service units with behind a load balancer, the unit-caches will diverge and the benefits will be lost. If you are concerned about internal PS4.5 network reliability (there is no evidence you should be), you need a common backend-cache layer (squid, ideally) shared across all your worker-units.

As I mentioned earlier, maybe not clearly, retrying 5xx will give your app resilience against broken backend workers (store units that are temporarily malfunctioning) but does not overcome any internal network outage and realistically speaking, nothing does. In case of an internal network outage, your app wouldn't be receiving any request in the first place and in this sense preparing for it in advance without evidences of what is the actual problem falls into "premature optimization".

Instead of adding layers of complexity at this early stage, I would advise instrumenting your application for tracking problems and timing the external requests, as we do in https://grafana.ubunet.canonical.com/dashboard/db/snapstore, then based on evidence you can react with the right tool.

If you are concerned about page load timing, since the backend is your only source of data, I'd rather cache the whole external page instead of the backend request. Obviously it poses challenges for authenticated access, but they are much easier to manage at the HTTP level than inside your code.

Take my comments as suggestions and if you feel strong about local caching feel free to continue to use it. I just don't think it will ever buy you the benefits you are looking for.

[nottrobin]

Yes, I take and agree with most of those points:

• For performance, we should do whole-page caching
• Network problems within PS4.5 would affect this app equally
• Protecting against fairly unlikely hypothetical problems is often wasteful premature optimisation

So you're right, the one case I am really guarding against is an error in the API itself. I don't feel that this is "premature optimisation" in this case because we have multiple times had critical websites (www.ubuntu.com, maas.io, www.canonical.com ...) expose 500 errors to the user because they relied on API calls in the back-end to other services (also within PS4.5, I believe) which went down, or started erroring, or took a long time to respond. We have this caching in API calls in our existing applications for this reason (as in, from postmortem optimisations) and I have simply copied it over because I think the risk applies just as much, if not more, to this application.

I am not questioning the quality of the Snapcraft API, I'm just saying I think it is wise to be resilient against it experiencing problems, as we've been bitten by exactly this many times in the past.

[bartaz]

@nottrobin Is this discussion still open or can it be closed?

[nottrobin]

I think it can be closed for now.