A follow button often looks like a tiny feature, but it represents a saved decision. If the interface says “Following” before a rejected request finishes, the listener may leave with the wrong idea about their library.
Choose whether the button uses a confirmed update or an optimistic update. Either approach can work when its failure behavior is clear.
Make the transition visible
With a confirmed update, keep the button busy until the backend accepts the operation. Prevent another click from starting an unrelated duplicate request. On success, show the saved state. On failure, return to the original state and offer a retry.
With an optimistic update, change the label immediately but keep track of the pending operation. If it fails, restore the earlier value and explain what happened. Avoid announcing a permanent save until your application's chosen confirmation point has been reached.
Keep the operation attached to the show ID and account that started it. A late response must not change the button for a different show after navigation or for another person after account switching.
Test quick interaction
Click follow twice under a slow connection. Navigate away before the response returns. Then return to the show page and compare the state with the server. Also test an authentication failure and a temporary service error.
For unfollow, decide what happens to saved episodes and existing downloads. Do not delete related data merely because the button's label changed unless that is an explicit product rule.
The UI should communicate one reliable fact: whether this account's follow choice has been saved. Keep that fact separate from cached catalog cards, visual animation, and the number of times the user tapped.