change newsletterSignupAgent.refresh period from 60 to 15 minutes

[dblatcher]

What is the value of this and can you measure success?

Frontend holds a cached copy of the newsletter api data in memory using the NewsletterSignupAgent, which the NewsletterSignupLifecycle refreshes every 60 minutes.

The newsletter API uses a fastly cache, so when frontend refreshes the data it gets will not be the latest version. In practise, this means that updates made to the newsletter data (which can be made by editorial using the newsletter tool take 1-2 hours to appear on the site.

Increasing the frequency to 15 minutes should be safe since:

• fetching and parsing the data from the API is not an expensive operation
• identity fetches the same data every 5 minutes, so frontend should never be 'ahead' of identity (if that happened, frontend might render sign-up forms for newsletters that identity doesn't have yet, so the sign-up requests to identity would fail)

What does this change?

Changes the frequency of the newsletterSignupAgent.refresh job in NewsletterSignupLifecycle from 60 to 15 minutes.

Checklist

• Tested locally, and on CODE if necessary
• Will not break dotcom-rendering
• Will not break our database – if updating CAPI, updated and committed the database files
• Meets our accessibility standards
  • Tested with screen reader
  • Navigable with keyboard
  • Colour contrast passed

[prout-bot]

Seen on ADMIN-PROD (merged by @dblatcher 12 minutes and 3 seconds ago)

• Check your changes on www.theguardian.com ✔️
• Keep an eye on the deploy dashboard 📉

[prout-bot]

Seen on FRONTS-PROD (merged by @dblatcher 12 minutes and 10 seconds ago)

• Check your changes on www.theguardian.com ✔️
• Keep an eye on the deploy dashboard 📉