Proposal for mobile-fastly-cache-purger

[silvacb]

Why are we doing this?

Fronts editors are frustrated that their updates take up to 5 minutes to show in apps. This is due to our Fastly cache times (the fronts response from MAPI are cached in Fastly with 5 mins TTL). We are working to get this delay reduced without unnecessarily increasing origin load, so we are exploring how to get notifications when there are updates to fronts in facia tool.

Proposal

We started with the idea that, every time there's an update to the fronts tool, the tool would push a message onto our queue, which in turn would trigger the lambda that purges the cache.

In previous conversations with the Content Production team, it's been suggested to create a single SNS topic that would fan out to multiple queues as a way of scaling this without having to change application code.

This would make the architecture ultimately look like this:

Architecture

The architecture that we have in place at the moment:

We have created a lambda and a queue (inside the mobile account):

that receives a message (for the purpose of testing, we created the message manually and kept the format equivalent to the message sent by the tool to the fronted queue (e.g. {"path":"app/front-mss","pressType":"draft","creationTime":1691061092190,"forceConfigUpdate":false}):

and purges the Fastly cache based on the front id extracted from the message:

Currently we are only purging a front using the front id, but we have a ticket in the backlog to get a list of all of the collections within a front (using the front id) and make additional purge requests for each of the collections within the updated front.

Further steps:

• create an SNS topic in the Content Production team's account
• subscribe the MSS and Dotcom queues to the SNS topic
• make the Fronts Tool push messages onto the topic instead of the individual queues.