The post loads in one read. Why is adding one comment becoming expensive?

One object is a convenient boundary, until it isn't

Embedding a title, a small author snapshot and a short list of labels inside one post document can be sensible. Those fields are commonly read together and do not grow without bound.

Embedding every comment seems like the same decision, but the workload is different. Comments grow independently. They have separate authors, moderation states and update rates. The page rarely needs all 100,000 at once.

MongoDB documents are limited to less than 16 MiB. That is a hard bound, not a performance target to approach intentionally. MongoDB's documentation describes embedding as useful when related fields are retrieved together and updated in a single atomic write, but it also states the document-size limit. MongoDB embedding

So I would start with the actual reads: post details, first page of comments, comments by one moderator, and replies to a specific comment. They do not all naturally share one document lifetime.

Move the unbounded part into its own collection

A practical model might have one posts document keyed by post ID and a comments collection keyed by comment ID, with postId, creation order, parent comment ID and moderation fields. The comment query uses an index matched to postId and the cursor sort order.

The first page can now fetch the post and a bounded comment page. That is more than one logical read operation, but it moves an amount of data proportional to the page size rather than the lifetime of the post.

A comment may be edited without continually contending with unrelated post metadata writes. Moderation can query by author, status or report identifiers through the indexes that correspond to those workflows.

If product wants five preview comments on the post card, I might keep a bounded preview snapshot in the post document as well. The important word is bounded. It is a deliberate duplicated read model, not an instruction to append every comment forever.

The tradeoff is now consistency between the comment collection and any preview or comment count. A count may lag or require reconciliation, depending on the product contract. For a moderation decision, the authoritative comment record should win over a stale preview. A small stale badge and an incorrectly visible prohibited comment are not equally acceptable inconsistencies.

The atomicity boundary changed

An important reason to embed related fields is atomic update within one document. Suppose a post title and its publication flag must change together. A single-document update can express that atomic modification. MongoDB embedding

After moving comments into a separate collection, updating the post and a comment is no longer one single-document operation. If a product feature genuinely needs those two changes to be all-or-nothing, the design needs a supported multi-document transaction or a workflow whose intermediate states are acceptable. Do not say “MongoDB cannot do transactions.” That is both inaccurate and unnecessary to the interview decision.

But transaction support is not a reason to embed an unbounded set. Data shape should reflect the dominant read and update patterns. Use cross-document coordination where a real business invariant requires it, not for every comment edit.

Think about deletion. If a moderator removes one comment, that comment record may be marked hidden while audit history remains, under the application's retention policy. If the post stores a cached preview, its invalidation should be scheduled or updated under an explicit freshness contract. Reading the old preview should never bypass the enforcement check for hidden content.

How do you migrate a large embedded array?

A production system may already have millions of existing posts with embedded comments. I would not flip the reader to a new collection before the data exists.

First, introduce readers that understand the old and new shapes under a schema version. Then backfill comments into a new collection with stable IDs and a record of which source ranges have been copied. During the backfill, live comments need one clear authoritative write route, plus a capture or dual-read strategy that prevents a comment from disappearing between source scan and cutover.

If the migration requires temporary dual writes, treat partial success as a real failure mode and have reconciliation. A versioned cutoff or generation pointer can tell readers which representation is authoritative. Verify samples, totals and ordering before retiring the old field. The exact mechanics depend on the available transaction and change-stream guarantees.

A migration that only compares aggregate comment counts can miss a duplicated comment canceling a missing one. Check identities and representative pagination boundaries too.

When embedding still wins

Suppose a post contains three poll options, each always read and updated with the post. Keeping those options embedded is natural. Separate collections would add reads and complicate an invariant without obvious benefit.

Now suppose comments are limited by product policy to ten, immutable after posting, and always displayed together. Embedding them may again be sensible. We should not promote a “never embed arrays” rule.

The useful interview answer comes from lifecycle, cardinality, access pattern and atomicity scope, not an arbitrary preference for normalization or denormalization.

The platform then adds full-text search across posts and comments. It creates another representation optimized for search. That representation can lag the primary documents, which creates a different type of correctness question.