ਸੇਵਾਵਾਂ ਵਿੱਚ ਤੁਸ਼ ਆਮ ਤੌਰ 'ਤੇ strong ਕਨਸਿਸਟੈਂਸੀ ਨੂੰ eventual ਕਨਸਿਸਟੈਂਸੀ ਲਈ ਬਦਲਦੇ ਹੋ، ਅਤੇ CQRS ਅਤੇ event sourcing 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋ ਤਾਂ ਕਿ ਇਹ ਪ੍ਰੈਕਟੀਕਲ ਅਤੇ ਸਹੀ ਹੋਵੇ।
ਇੱਕ ਪਰਿਵਰਤਨ ਤੋਂ ਬਾਅਦ، replicas "ਜਲਦੀ" ਬਦਲੇ ਵਿੱਚ convergence ਕਰਦੇ ਹਨ ਬਜਾਏ ਤੁਰੰਤ ਤੋਂ। ਬਹੁਤ ਸਾਰੇ ਕਾਰੋਬਾਰੀ ਪ੍ਰਵਾਹਾਂ ਲਈ ਸਵੀਕਾਰਯੋਗ (ਇੱਕ inventory count ਇੱਕ ਸਕਿੰਟ ਪਿੱਛੇ ਸਕ ਸਕਦਾ ਹੈ)، ਕੁਝ ਲਈ ਅਸਵੀਕਾਰਯੋਗ (ਇੱਕ bank balance check)।
write model ਨੂੰ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ read models ਤੋਂ ਵੱਖ ਕਰੋ।
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Reads ਲਿਖਤ ਤੋਂ ਸੁਤੰਤਰ ਢੰਗ ਨਾਲ ਸਕੇਲ ਅਤੇ reshape ਕਰਦੇ ਹਨ; read model ਈਵੈਂਟਾਂ ਤੋਂ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ، ਇਸ ਲਈ ਇਹ eventually consistent ਹੈ।
ਈਵੈਂਟਾਂ ਦਾ ਕ੍ਰਮ ਨੂੰ source of truth ਵਜੋਂ ਸਟੋਰ ਕਰੋ، ਸਿਰਫ ਮੌਜੂਦਾ state ਨਹੀਂ। ਮੌਜੂਦਾ state ਈਵੈਂਟਾਂ ਉੱਤੇ ਇੱਕ fold ਹੈ।
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technique | Gains | Costs |
|---|---|---|
| Eventual consistency | Availability, scale | Stale reads, conflicts |
| CQRS | Read/write scale | Two models ਨੂੰ sync ਵਿੱਚ ਰੱਖਣਾ |
| Event sourcing | Audit, replay, history | Schema/event evolution, complexity |
Event sourcing ਨੂੰ ਹਰ ਥਾਂ ਅਪਣਾਓ ਨਾ — ਇਹ ਸ਼ਕਤੀਸ਼ਾਲੀ ਪਰ ਭਾਰੀ ਹੈ। ਇਸਨੂੰ ਉਥੇ ਵਰਤੋ ਜਿੱਥੇ audit/history ਸੱਚਮੁੱਚ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
Distributed systems ਕੋਲ strong consistency، availability، ਅਤੇ partition tolerance ਸਭ ਇਕਸਾਥ ਨਹੀਂ ਹੋ ਸਕਦੇ، ਇਸ ਲਈ senior design ਇਸ ਬਾਰੇ ਚੁਣਨਾ ਹੈ ਕਿ eventual consistency ਕਿੱਥੇ ਸਵੀਕਾਰਯੋਗ ਹੈ।
CQRS ਅਤੇ event sourcing ਤੁਹਾਨੂੰ eventual consistency ਨੂੰ reliable ਅਤੇ auditable ਬਣਾਉਣ ਲਈ ਔਜ਼ਾਰ ਦਿੰਦੇ ਹਨ — ਪਰ ਹਰ ਇੱਕ ਸਰਵ complexity ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ، ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ surgically ਲਾਗੂ ਕਰੋ، ਮੂਲ ਤੌਰ 'ਤੇ ਨਹੀਂ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ