Why should you care?

One viral post with a million likes should not force every post document to use the heavy design. Handle the exception separately.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

db.posts.insertOne({
  _id: ObjectId("64b000000000000000000001"),
  title: "Normal post",
  likeCount: 12,
  likedBy: [1, 2, 3] // small list embedded
})
db.posts.insertOne({
  _id: ObjectId("64b000000000000000000099"),
  title: "Viral post",
  likeCount: 1000000,
  likesOverflow: true
})
db.postLikes.insertOne({
  postId: ObjectId("64b000000000000000000099"),
  userId: 42,
  at: new Date()
})
db.posts.find({ likesOverflow: { $ne: true } })

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• Normal posts embed a small likedBy array.
• The viral post sets likesOverflow and stores individual likes in postLikes.
• Most reads stay simple; outliers use the side collection.

Practice next

1. Insert both posts and one overflow like.
2. Write app logic: if likesOverflow then query postLikes.
3. Convert a post to overflow when likedBy.length exceeds 100.
4. Add an overflow threshold constant in your notes (e.g. 100).
5. Index postLikes on { postId: 1, userId: 1 } uniquely.

Remember

Optimize for the common case. Move rare huge relations aside. Flag outliers explicitly.

Celebrity account followers

A social app embeds follower ids for normal users but stores celebrity followers in a sharded followers collection.

Outcome: 99% of profiles stay tiny; mega-accounts still scale.