MusixMatch_API_ADR.md

ADR #0001: MusixMatch API

Date: 2020-07-09

Who

• Manu Phatak

Status

Draft

Context

MusixMatch is a 3rd party API that provides critical information used by this App. We want to explore options to mitigate any incidents where our vendor cannot deliver the data our users need.

Options

Caching

There's a variety of options here that go into caching data from MusixMatch' API. The common theme is that we want to keep some copy of the data in our DB and serve it as a Plan A, Plan B, or first-come-first-serve.

Option 1: Serve local data

Serving our copy of the data is Plan A. Following this strategy, we serve data from our database. In the background, we routinely update our DB with data from our vendor.

Pros

• We take maximum ownership of delivering our data
• We can make performance optimizations that our vendor can't

Cons

• We'll need a mechanism to keep data fresh. This mechanism could be a background job dispatched with requests for data; alternatively, if new charts are released on a schedule, we could use a cron job.

Option 2: Caching as a fallback

Our copy of the data is Plan B.

We could try to serve data from our vendor and fall back to cached data when needed.

Pros

• Data will be fresh, served directly from our vendor.

Cons

• This strategy does not mitigate degraded service from our vendor. For example, their endpoint could be slow or even timing out before failing, and that delay would block this strategy. We could mitigate against this with a feature flag mechanism, but that would require manual intervention.

Option 3: First Come First Serve

Using this strategy, we ask both our DB and our vendor for the data we need in parallel. We serve our users with whatever data we get back first.

In the background, we can keep our database up to date.

Pros

• As the fastest server wins, our users win.
• Data stays up to date.
• Mitigate against both outages and degraded service from our vendor.

Cons

• Our server will usually win, so there will be a lot of unnecessary traffic to our vendor.
• We would have to manage async workflows increasing complexity.

Multiple and Alternative Vendors

There are alternatives to MusixMatch, including

• https://www.last.fm/api
• https://developer.spotify.com/documentation/web-api/
• others, TBD

Option 4: First Come First Serve with multiple vendors

We could make requests from multiple providers (including our cache) and serve whatever comes back first.

Pros

• Our users get the fastest and freshest content on the internet.

Cons

• Money.
• Resources.
• This is total overkill.

Decision

We will go with Option 1 and serve users data from our Production DB. We will periodically update our database with our vendors' data.

We will serve data from our DB as Plan A because it will be fast and reliable. There are no known requirements for real-time data streams. As is, charts from MusixMatch don't even have timestamps. To keep data fresh, we will run a cron job every 6 hours to check every country's charts.

When/if we discover new requirements for fresher data, we can explore other options, including tweaking the refresh period or even an alternative strategy altogether.