A 'list users' API became slow and memory-heavy after you added profile fields, avatars, and a preferences object. The query is still find({ city }). What went wrong?

Short answer

The query returns whole documents. Every extra field you embed is now on the hot list path. Project the fields the list actually needs, and keep large or rarely used data off the user document — or behind a separate read.

Why?

Flexible schema makes it easy to pile fields onto users. The list endpoint does not need bio, settings, or a base64 avatar. Projection is the immediate fix; splitting rarely-read blobs is the modelling fix. This is the same lesson as covering indexes: do not ship what you will throw away.

Example

db.users.find(
  { city: "Bangalore" },
  { name: 1, email: 1, city: 1 }
).limit(20)

Interview tip

Talk about the read path first: 'what does the UI need?' That is how you decide projection vs splitting the document.

Common mistake

Blaming the network or Node.js GC before checking document size and the projection.