Your dream job? Lets Git IT. Interactive technical interview preparation platform designed for modern developers.
© 2026 LetsGit.IT. All rights reserved.
Sharded MongoDB: why are “scatter-gather” queries bad and how do you avoid them? | LetsGit.IT
LetsGit.IT / Categories / MongoDB Answer If a query doesn’t include the shard key (or its useful prefix), `mongos` may have to ask many shards and merge results (“scatter-gather”), which increases latency and load. You avoid it by choosing a shard key that matches your common query patterns and by ensuring queries include it.
Advanced answer Deep dive Expanding on the short answer — what usually matters in practice:
Context (tags): mongo, sharding , shard-key, performance Data model and access patterns: dominant queries (read/write ratio, sorting, pagination). Indexes: when they help vs hurt (write amplification, memory). Consistency & transactions: what’s guaranteed and what can bite you. Explain the "why", not just the "what" (intuition + consequences). Trade-offs: what you gain/lose (time, memory, complexity, risk). Edge cases: empty inputs, large inputs, invalid inputs, concurrency. Examples A tiny example (query + projection):
// Example: query + projection
const user = await db.collection('users').findOne(
{ email: '[email protected] ' },
{ projection: { _id: 0, email: 1, name: 1 } },
)Common pitfalls Too generic: no concrete trade-offs or examples. Mixing average-case and worst-case (e.g., complexity). Ignoring constraints: memory, concurrency, network/disk costs. Interview follow-ups When would you choose an alternative and why? What production issues show up and how do you diagnose them? How would you test edge cases?
#aggregation