How do you ensure data consistency in a sharded MongoDB cluster?
Ensure consistency in sharded MongoDB with the right shard key, majority read/write concerns, causal sessions, and distributed transactions.
Expected Interview Answer
You ensure consistency in a sharded MongoDB cluster by combining a well-chosen shard key, appropriate read and write concerns (such as majority), causally consistent sessions, and multi-document transactions when needed, so reads and writes behave predictably even though data is distributed across shards.
Each shard is a replica set, so within a shard you get strong consistency using writeConcern majority and readConcern majority or linearizable. Across shards, MongoDB routes queries through mongos using the config servers' metadata; a good shard key keeps related data together and enables targeted (not scatter-gather) queries. For operations spanning multiple documents or shards, distributed multi-document transactions provide atomicity and snapshot isolation, while causal consistency in a client session guarantees read-your-own-writes ordering.
- writeConcern majority ensures writes survive replica-set failovers
- readConcern majority/linearizable avoids reading rolled-back data
- A good shard key enables targeted queries and even data distribution
- Causal consistency gives read-your-own-writes within a session
- Multi-document transactions give atomicity across shards when required
AI Mentor Explanation
A sharded cluster is like scoring a tournament across many grounds at once. Each ground (shard) is a panel of scorers (the replica set) who agree before a run is official — that agreement is writeConcern majority. The central scoreboard operator (mongos) knows which ground holds which match via a master fixture list (config servers), so a query for one team goes straight to the right ground instead of interrupting every venue.
Step-by-Step Explanation
Step 1
Choose a strong shard key
Pick a key with high cardinality and even access that keeps related documents together, enabling targeted queries and avoiding hotspots or scatter-gather.
Step 2
Rely on replica-set consistency per shard
Each shard is a replica set; use writeConcern 'majority' so acknowledged writes survive primary failover without rollback.
Step 3
Set appropriate read concern
Use readConcern 'majority' (or 'linearizable' on the primary) so reads never return data that could be rolled back.
Step 4
Use causally consistent sessions
Run related operations in a client session with causal consistency to guarantee read-your-own-writes and monotonic reads.
Step 5
Wrap cross-document work in transactions
Use multi-document (distributed) transactions with snapshot read concern for atomic, isolated changes spanning documents or shards.
Step 6
Trust the routing metadata
mongos routes via config servers' chunk metadata; keep balancer and metadata healthy so queries reach the correct shard(s).
What Interviewer Expects
- Understanding that each shard is a replica set
- Role of writeConcern majority and readConcern majority/linearizable
- How shard-key choice affects targeting and hotspots
- Causal consistency for read-your-own-writes in a session
- When and how multi-document/distributed transactions apply
- Role of mongos and config servers in routing
Common Mistakes
- Assuming sharding alone guarantees consistency without tuning concerns
- Using writeConcern 1, risking data loss on failover
- Choosing a monotonically increasing shard key that creates a hotspot
- Expecting cross-shard queries to be atomic without a transaction
- Confusing sharding (horizontal partitioning) with replication (copies)
- Ignoring read preference, then reading stale data from secondaries
Best Answer (HR Friendly)
“In a sharded MongoDB setup the data is spread across many servers, so you use settings that make sure writes are safely agreed on by a majority of copies and that reads don't see data that might disappear. Picking the right way to split the data and using transactions for changes that touch several records keeps everything consistent.”
Code Example
// Durable write that survives failover
await db.collection('orders').insertOne(
{ _id: orderId, userId, total },
{ writeConcern: { w: 'majority', wtimeout: 5000 } }
);
// Read that never returns rolled-back data
const order = await db.collection('orders')
.find({ _id: orderId })
.readConcern('majority')
.next();const session = client.startSession({ causalConsistency: true });
try {
await session.withTransaction(async () => {
const orders = db.collection('orders');
const inventory = db.collection('inventory');
await orders.insertOne({ _id: orderId, sku, qty }, { session });
await inventory.updateOne(
{ sku },
{ $inc: { available: -qty } },
{ session }
);
}, {
readConcern: { level: 'snapshot' },
writeConcern: { w: 'majority' }
});
} finally {
await session.endSession();
}Follow-up Questions
- What makes a shard key good, and what are the risks of a monotonic key?
- How does readConcern 'linearizable' differ from 'majority'?
- What guarantees do MongoDB distributed transactions provide across shards?
- How does causal consistency deliver read-your-own-writes?
- What role do config servers and mongos play in a sharded cluster?
MCQ Practice
1. Why is writeConcern 'majority' important in a sharded cluster?
With majority, a write is acknowledged only after a majority of the shard's replica set has it, so it won't be rolled back if the primary fails.
2. What is a common consequence of a monotonically increasing shard key?
Monotonic keys send all new inserts to the same chunk/shard, creating a hotspot instead of spreading load evenly.
3. Which mechanism gives atomicity for changes spanning multiple documents or shards?
Multi-document transactions provide all-or-nothing atomicity and snapshot isolation across documents and shards.
Flash Cards
What is each shard internally? — A replica set, so within a shard you get strong consistency via majority write/read concern.
Purpose of writeConcern majority? — Acknowledged writes are stored on a majority of the replica set, surviving primary failover without rollback.
Why does shard-key choice matter for consistency/perf? — A high-cardinality, evenly accessed key enables targeted queries and avoids hotspots and scatter-gather.
What gives read-your-own-writes across operations? — A causally consistent client session.
How do you make cross-shard changes atomic? — Use multi-document (distributed) transactions with snapshot read concern and majority write concern.