A podcast title, description, artwork, or feed address can change after a listener follows it. Those updates should refresh the show page without deleting the person's relationship with the show.
The key design choice is to keep catalog data and listener state separate. Catalog data describes the podcast. Listener state describes what a particular person did with it.
Use references instead of copied ownership
A follow record can reference a stable catalog ID. A saved episode can reference an episode ID while keeping a small display snapshot for offline use. Updating the catalog record then does not require rebuilding every user's saved list.
Decide which snapshot fields are acceptable to keep. An old title can be useful in a historical notification, but a current show page should normally prefer the newest known metadata. Do not overwrite listener-created notes with publisher text.
When receiving a documented change event, treat it as a reason to refresh the relevant data. Keep the event's identity and the refresh outcome so duplicate delivery does not trigger uncontrolled repeated work.
Test a realistic edit
Change a show's name and cover while preserving its catalog ID. Check that the follower count in your own system, saved episodes, and playback records remain attached. Then open an old deep link and an offline cached card.
Also test a record that becomes unavailable. Keep enough context to explain what happened rather than rendering an empty saved row.
A clean separation makes future migrations easier. You can improve search metadata or switch display rules without asking listeners to follow all their favorite shows again. The API contract should remain the authority for which fields and change events are supported.