Started working with Firestore recently, and after going through some of the official guides, it looks like in NoSQL databases it's desirable to optimize data organization for easy reads. In this video, it's suggested that a small chunk of user information can be duplicated and stored with the review written by the user, so that when retrieving the data, we can only retrieve the review document and still have enough information to render the author's name and profile picture. The argument being that way more reads are going to happen on the review, where as the user will change their name or profile picture much less frequently.
This all makes sense, but my question is, to what extent can this be applied? For instance, on a social networking app like instagram, a user might go around making many comments on various posts. The number of comments could easily grow into the thousands or tens of thousands, so when the user does eventually update their name or profile picture, will you then have to go and update every comment the user has ever made? This seems inefficient/impractical and error prone to someone used to relational databases, but is this just the way it is for NoSQL, and that it actually doesn't cause much of a problem in practice, or, in situations where the number gets large, we should still store the user info separately and combine it with the comment info when retrieving?
Another more extreme example: a user on instagram can see a list of the people they follow. Following the same logic, I imagine I'd want to store this information with the user object. When one of the users I follow changes their profile, they'll then update their entry in my list of people I follow. However, a celebrity could have millions of followers, so when they update their profile, they'll need to update it in the "following" list of their millions of followers as well. Does this actually work in practice, or does it break down as things scale?
