API Design With Relationships: Interview Questions

API Design With Relationships: Interview Questions

Interviewers ask these questions often. Here are concise answers.

Q1: How do you handle relationships in MongoDB?

Use refs (ObjectId fields with ref) and populate on read. For high-traffic reads, denormalize (copy key fields). For large N (messages, comments), use a separate collection with a ref. For small, tightly coupled data, embed.

Q2: What is the N+1 problem and how do you fix it?

Looping over documents and calling findById for each reference does N+1 queries. Fix: use populate to do it in 2 queries (one for the parent, one for all referenced docs).

Q3: When do you embed vs reference in MongoDB?

Embed for small, tightly coupled data that always loads together (an address in a user). Reference for one-to-many with large N (messages, comments, payments). Embedding large arrays bloats documents; use refs.

Q4: How do you populate in Mongoose?

.populate('authorId', 'firstName lastName'). Replaces the ObjectId with the referenced document, selecting only the specified fields. Always select; never return the entire referenced document.

Q5: What is denormalization in MongoDB?

Copying data where you need it (e.g., storing the author's name on the post). Faster reads (no join). Risk of stale data. Use for high-traffic reads of rarely-changing data. Decide whether to update on change or accept staleness.

Q6: How do you handle cascade deletes in MongoDB?

Delete related documents in the same handler. Use deleteMany for each related collection, then delete the parent. Do it in a transaction if your MongoDB supports it, so a failure rolls back.

Q7: How do you paginate with populate in Mongoose?

populate works with skip and limit. Post.find().sort({ createdAt: -1 }).skip(20).limit(20).populate('authorId', 'firstName'). Be careful with large limits; populate does an extra query for all referenced docs.

Q8: How do you filter by a referenced field in MongoDB?

Use match in populate: Post.find().populate({ path: 'authorId', match: { role: 'admin' } }). Posts with non-admin authors get authorId: null. Filter them out in code if needed.

Q9: What is side-loading in APIs?

For lists with many relationships, fetch parents and referenced docs in parallel, return both, let the client connect them. Avoids N+1 and avoids large nested payloads. Example: { posts: [...], authors: [...] }.

Q10: How do you handle stale data with denormalization?

Either update on change (when the user's name changes, update all their posts; expensive but consistent) or accept staleness (the name on old posts stays as it was; cheaper, fine for many cases like chat messages). Decide based on the feature's needs and document the decision.

The Takeaway

API design with relationships: refs and populate; fix N+1 with populate; embed for small data, reference for large N; always select fields when populating; denormalize for high-traffic reads; cascade delete in a transaction; paginate with populate; filter by referenced field with match; side-load for lists; handle staleness with a plan.