write concern ਅਤੇ read concern consistency ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ?

Question

IT Interview Practice · Accepted Answer

**Write concern** ਅਤੇ **read concern** MongoDB ਵਿੱਚ consistency ਅਤੇ durability ਦੀਆਂ ਗਰੰਟੀਆਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੇ ਹਨ (replica sets ਵਿੱਚ) — **performance** ਅਤੇ **safety/consistency** ਦੇ ਵਿੱਚ trade-off ਕਰਦੇ ਹੋਏ। ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਟਿਊਨ ਕਰਨ ਦਿੰਦੇ ਹਨ ਕਿ writes ਕਿੰਨੀ ਸਖ਼ਤੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ reads ਕਿੰਨੀ consistent ਹਨ, ਡੇਟਾ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਆਧਾਰ ਤੇ।

## Write concern — writes ਦੀ durability

```js
// write concern: how many nodes must acknowledge a write
db.orders.insertOne(doc, { writeConcern: { w: 1 } });           // primary only — fast
db.orders.insertOne(doc, { writeConcern: { w: "majority" } });   // majority of nodes — safe
db.orders.insertOne(doc, { writeConcern: { w: "majority", j: true } }); // + journaled to disk
```

```text
w: 1          → only the PRIMARY acknowledges (fast, but a write could be LOST on failover)
w: "majority" → a majority of nodes acknowledge → the write SURVIVES primary failover
               (no data loss) — safer but slower (waits for replication)
j: true       → also wait for the write to be written to the JOURNAL (disk durability)
```

**Write concern** durability ਨੂੰ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ: `w: "majority"` ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ write majority ਨੂੰ replicate ਹੁੰਦਾ ਹੈ (failover ਤੋਂ ਬਿਨਾ ਨੁਕਸਾਨ ਬਚ ਜਾਂਦਾ ਹੈ) ਪਰ ਇਹ ਹੌਲ਼ਾ ਹੈ; `w: 1` ਤੇਜ਼ ਹੈ ਪਰ ਜੇ primary ਫੇਲ ਹੋ ਜਾਵੇ replication ਤੋਂ ਪਹਿਲਾਂ ਤਾਂ write ਗੁਆ ਸਕਦਾ ਹੈ।

## Read concern — reads ਦੀ consistency

```js
db.orders.find().readConcern("majority");   // read data acknowledged by a majority
```

```text
local        → returns the most recent data on the node (may not be majority-committed,
               could be rolled back) — default, fast
majority     → returns only data acknowledged by a majority (won't be rolled back) — consistent
linearizable → strongest (reflects all prior majority writes) — slowest
```

**Read concern** ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ ਕਿ reads ਕਿਹੜਾ ਡੇਟਾ ਦੇਖਦੇ ਹਨ: `majority` ਸਿਰਫ majority-committed ਡੇਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ (rollback ਨਹੀਂ ਹੋਵੇਗਾ — consistent), `local` ਤੁਲਨਾ ਵਿੱਚ (ਨਵੀਨਤਮ local ਡੇਟਾ, ਸ਼ਾਇਦ ਅਜੇ majority-committed ਨਹੀਂ)।

## The consistency vs performance trade-off

```text
Stronger guarantees (w: majority, readConcern: majority) → safer, consistent, but SLOWER
Weaker guarantees (w: 1, readConcern: local) → faster, but risk of data loss on failover
  or reading not-yet-durable data
→ Choose based on the data: critical data (payments) → strong; less critical → faster.
→ Reading from secondaries adds eventual-consistency considerations (stale reads).
```

## ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

Write concern ਅਤੇ read concern ਨੂੰ ਸਮਝਣਾ MongoDB replica sets ਵਿੱਚ **consistency-vs-performance trade-off ਨੂੰ ਮੈਨੇਜ ਕਰਨ** ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਇਸ ਲਈ ਇਹ ਸਹੀ, ਢੁਕਵੀਂ-tuned distributed MongoDB applications ਬਣਾਉਣ ਲਈ ਮਹੱਤਵਪੂਰਨ senior-level ਜਾਣਕਾਰੀ ਹੈ।

ਇਹ settings MongoDB ਦੀ consistency ਅਤੇ durability ਦੀਆਂ ਗਰੰਟੀਆਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਮਝਣਾ ਜ਼ਰੂਰੀ ਹੈ ਤਾਂ ਜੋ ਡੇਟਾ ਨੂੰ ਇਸ ਦੀ ਮਹੱਤਤਾ ਲਈ ਸੁਰੱਖਿਆ ਦੇ ਸਹੀ ਪੱਧਰ ਨਾਲ ਹੈਂਡਲ ਕੀਤਾ ਜਾਵੇ। **Write concern** ਖਾਸ ਤੌਰ ਤੇ **durability** ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ: `w: "majority"` ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ write majority nodes ਨੂੰ replicate ਹੁੰਦਾ ਹੈ (primary failover ਤੋਂ ਬਿਨਾ ਡੇਟਾ ਗੁਆਣ ਦੇ ਬਚ ਜਾਂਦਾ ਹੈ — payments ਜਾਂ orders ਵਰਗੇ ਮਹੱਤਵਪੂਰਨ ਡੇਟਾ ਲਈ ਨਾਜ਼ੁਕ), ਜਦੋਂ ਕਿ `w: 1` ਤੇਜ਼ ਹੈ ਪਰ ਜੇ primary ਫੇਲ ਹੋ ਜਾਵੇ replication ਤੋਂ ਪਹਿਲਾਂ ਤਾਂ write ਗੁਆ ਸਕਦਾ ਹੈ — ਇਹ ਮਹੱਤਵਪੂਰਨ trade-off ਹੈ ਜਿੱਥੇ ਗਲਤ ਚੁਣਾਵ failover ਤੇ silent ਡੇਟਾ ਗੁਆਣ ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ। **Read concern** **read consistency** ਨੂੰ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ: `majority` ਸਿਰਫ majority-committed ਡੇਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ (consistent, rollback ਨਹੀਂ ਹੋਵੇਗਾ) ਬਨਾਮ `local` (ਨਵੀਨਤਮ ਡੇਟਾ, ਸ਼ਾਇਦ ਅਜੇ durable ਨਹੀਂ ਅਤੇ rollback ਦੀ ਸੰਭਾਵਨਾ) — ਇਹ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੀ reads ਅਜਿਹਾ ਡੇਟਾ ਦੇਖ ਸਕਦੇ ਹਨ ਜੋ ਬਾਅਦ ਵਿੱਚ ਗਾਇਬ ਹੋ ਜਾਵੇ।

Trade-off ਨੂੰ ਸਮਝਣਾ — ਮਜ਼ਬੂਤ ਗਰੰਟੀਆਂ (majority) ਸੁਰੱਖਿਤ ਅਤੇ ਵਧੇਰੇ consistent ਹਨ ਪਰ ਹੌਲ਼ੀ, ਜਦੋਂ ਕਿ ਕਮਜ਼ੋਰ ਗਰੰਟੀਆਂ ਤੇਜ਼ ਹਨ ਪਰ ਡੇਟਾ ਗੁਆਣ ਜਾਂ inconsistent reads ਦਾ ਖਤਰਾ — ਅਤੇ ਡੇਟਾ ਦੀ criticality ਦੇ ਆਧਾਰ ਤੇ ਚੁਣਨਾ (ਮਹੱਤਵਪੂਰਨ ਡੇਟਾ ਲਈ ਮਜ਼ਬੂਤ, ਘੱਟ ਨਾਜ਼ੁਕ ਲਈ ਤੇਜ਼) — ਇਹ ਮੁੱਖ ਨਿਰਣਾ ਹੈ।

ਇਹ ਵੀ ਪ੍ਰਾਸੰਗਿਕ ਹੈ ਕਿ secondaries ਤੋਂ ਪੜ੍ਹਨਾ eventual-consistency ਵਿਚਾਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ (stale reads)।

ਕਿਉਂਕਿ ਡੇਟਾ consistency ਅਤੇ durability critical ਹਨ (ਅਤੇ ਸਹੀ ਪੱਧਰ ਡੇਟਾ ਤੇ ਨਿਰਭਰ ਹੈ), ਅਤੇ ਕਿਉਂਕਿ write/read concern ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਇਹਨਾਂ ਗਰੰਟੀਆਂ ਨੂੰ MongoDB ਦੇ distributed (replica set) architecture ਵਿੱਚ performance ਦੇ ਵਿਰੁੱਧ tune ਕਰਦੇ ਹੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਸਮਝਣਾ — durability/consistency ਦੇ ਪੱਧਰ, performance trade-off, ਅਤੇ appropriately ਚੁਣਨਾ — ਸਹੀ distributed MongoDB applications ਬਣਾਉਣ ਲਈ ਮਹੱਤਵਪੂਰਨ senior-level ਜਾਣਕਾਰੀ ਹੈ, ਇੱਕ ਅਜਿਹਾ ਟਾਪਿਕ ਜੋ distributed-systems consistency trade-offs ਦੀ ਸਮਝ ਦਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਖਾਸ ਤੌਰ ਤੇ applications ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿੱਥੇ ਡੇਟਾ ਗੁਆਣ ਜਾਂ inconsistency ਮਹਿੰਗੀ ਹੋਵੇ।

Write concern — writes ਦੀ durability

Read concern — reads ਦੀ consistency

The consistency vs performance trade-off

ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ