The whole "...we don’t want duplicated subscriber lists" is a very arbitrary requirement.<p>What's more, all this could have been avoided if a proper relational database structure (not even denormalized, GordonS) was there in the first place.
Why not use a materialized view?<p><a href="https://www.postgresql.org/docs/9.3/sql-creatematerializedview.html" rel="nofollow">https://www.postgresql.org/docs/9.3/sql-creatematerializedvi...</a>
"Because order should not matter, both arrays are sorted before they are compared."<p>I do not understand this line very well. If order does not matter, why sort anything?
I applaud the effort put in for performance, but why not just enqueue the change notification and do the sends on the back end? This sort of fiddly process is exactly why deferred action is appropriate.
TL;DR: a short article describing a normalised schema, with big performance gains when denormalising data.<p>Article is very application-specific, but is perhaps a reminder that denormalisation can be useful when working with relational databases.