Thank you for your response.
Regarding the extended-reference-pattern, when you mentioned to update at application level, you meant to say that whenever profile name is updated, it will triggers a update to all collections
db.collA.updateMany({'epd.profile_key': '12345'},{$set: {'epd.profile_name': 'new'}})
db.collB.updateMany({'epd.profile_key': '12345'},{$set: {'epd.profile_name': 'new'}})
db.collC.updateMany({'epd.profile_key': '12345'},{$set: {'epd.profile_name': 'new'}})
// and so on
The cons of this would be that the application would need to know what are the available collections, and update it whenever there is an new collection. Am I right to say so? Bringing the example slightly further, if there is below 100k documents per such collection (maybe 1 or 2 would have more, say up to a million), would there be any different between using updateMany and bulkWrite. When should I use one over another?
Going back to the other options as mentioned, triggers don’t look an option to me since it’s a on-prem setup, and my current thinking is to go with something like change-stream, where it listens for the change, and then update all the collections that needs to be updated. Would I need to be mindful of concurrency issue here, where some other actions triggers an update to the document, then the change-stream triggers the update?
// profile.name gets updated
// change-stream detected change, running the update across collections (a-z)
// another operation trigger an update to collection-f doc
// change-stream update the docs with the updated profile.name but overwrites the previous update (above)
Thanks for the suggestion regarding the subset-pattern