एडमिन टूल्स के लिए ऑप्टिमिस्टिक लॉकिंग: चुपचाप ओवरराइट रोकें

समस्या: कई लोग संपादित करते समय चुपचाप ओवरराइट होना

“साइलेंट ओवरराइट” तब होता है जब दो लोग एक ही रिकॉर्ड खोलते हैं, दोनों बदलाव करते हैं, और आख़िरी व्यक्ति जब Save दबाता है तो उसकी बात लागू हो जाती है। पहले व्यक्ति के बदलाव गायब हो जाते हैं — अक्सर बिना किसी चेतावनी के और बिना आसान रिकवरी के तरीके के।

एक व्यस्त एडमिन पैनल में यह दिन भर होता रह सकता है बिना किसी के ध्यान दिए। लोग कई टैब्स खोल कर रखते हैं, टिकट्स के बीच कूदते हैं, और 20 मिनट बाद किसी फॉर्म पर लौटते हैं। जब वे सेव करते हैं, तो वे रिकॉर्ड के नवीनतम संस्करण को अपडेट नहीं कर रहे होते — वे उसे ओवरराइट कर रहे होते हैं।

यह बैक-ऑफिस टूल्स में ज़्यादा दिखाई देता है क्योंकि काम सहयोगी और रिकॉर्ड-आधारित होता है। आंतरिक टीमें बार-बार एक ही ग्राहक, ऑर्डर, उत्पाद और अनुरोध एडिट करती हैं। सार्वजनिक ऐप्स में अक्सर “एक यूजर अपनी चीजें एडिट करता है” होता है, जबकि एडमिन टूल्स में “कई यूजर साझा चीजें एडिट करते हैं” होता है।

हालाँकि क्षति अक्सर तात्कालिक रूप से बड़ा नहीं लगती, पर यह जल्दी बढ़ जाती है:

• एक उत्पाद की कीमत पुरानी वैल्यू पर वापस चली जाती है प्रमो अपडेट के तुरंत बाद।
• सपोर्ट एजेंट का इंटरनल नोट गायब हो जाता है, इसलिए अगले एजेंट को वही ट्रबलशूटिंग दोहरानी पड़ती है।
• एक ऑर्डर की स्थिति उलटी हो जाती है (उदा. “Shipped” से वापस “Packed”), जिससे गलत follow-up ट्रिगर हो सकता है।
• ग्राहक का फ़ोन नंबर या पता पुराना हो कर बदल दिया जाता है।

साइलेंट ओवरराइट इसलिए कष्टदायक होते हैं क्योंकि हर कोई सोचता है सिस्टम ने सही से सेव किया। कोई स्पष्ट “कुछ गलत हुआ” क्षण नहीं होता, बस बाद में रिपोर्ट्स मिक्स दिखती हैं या कोई teammate पूछता है, “यह किसने बदला?”

ऐसे कन्फ्लिक्ट सामान्य हैं — यह संकेत है कि टूल साझा और उपयोगी है, न कि कि टीम कुछ गलत कर रही है। उद्देश्य दो लोगों को एडिट न करने से रोकना नहीं है, बल्कि यह पता लगाना है कि रिकॉर्ड संपादित करते समय बदल गया और फिर उस स्थिति को सुरक्षित तरीके से संभालना है।

यदि आप AppMaster जैसे नो‑कोड प्लेटफ़ॉर्म में आंतरिक टूल बना रहे हैं, तो इसे पहले से योजना में रखना अच्छा है। एडमिन टूल्स तेजी से बढ़ते हैं, और जब टीमें उन पर निर्भर हो जाती हैं, तो कभी-कभी डेटा खोना भरोसे पर असर डाल देता है।

ऑप्टिमिस्टिक लॉकिंग सरल शब्दों में

जब दो लोग एक ही रिकॉर्ड खोलते हैं और दोनों Save पर क्लिक करते हैं, तो आपके पास concurrency होता है। हर व्यक्ति ने एक पुराना snapshot देखा था, लेकिन एक ही समय में केवल एक ही “नवीनतम” हो सकता है जब सेव्स हो रही हों।

बिना सुरक्षा के, आख़िरी सेव जीत जाती है। यही साइलेंट ओवरराइट का कारण है: दूसरा सेव चुपचाप पहले वाले के बदलाव को रिप्लेस कर देता है।

ऑप्टिमिस्टिक लॉकिंग एक सरल नियम है: “मैं अपनी बदलें तभी सेव करूँगा जब रिकॉर्ड उसी स्थिति में हो जैसा मैंने एडिट शुरू करते समय देखा था।” अगर बीच में रिकॉर्ड बदल गया है, तो सेव reject कर दे और यूजर को एक conflict दिखाएँ।

यह pessimistic locking से अलग है, जो कुछ हद तक “मैं इसे एडिट कर रहा हूँ, इसलिए कोई और नहीं कर सकता” जैसा व्यवहार है। पेसिमिस्टिक लॉकिंग में अक्सर हार्ड लॉक, टाइमआउट और लोग ब्लॉक हो जाते हैं। यह कुछ दुर्लभ मामलों (जैसे खातों के बीच पैसे ट्रांसफर) में उपयोगी हो सकता है, पर व्यस्त एडमिन टूल्स में यह झुंझलाहट पैदा करता है।

ऑप्टिमिस्टिक लॉकिंग आमतौर पर बेहतर डिफॉल्ट होता है क्योंकि यह काम को प्रवाहित रखता है। लोग समानांतर में एडिट कर सकते हैं, और सिस्टम केवल वास्तविक टकराव पर हस्तक्षेप करता है।

यह तब सबसे अच्छा बैठता है जब:

• कन्फ्लिक्ट संभव हैं पर लगातार नहीं होते।
• एडिट जल्दी होते हैं (कुछ फ़ील्ड, एक छोटा फॉर्म)।
• दूसरों को ब्लॉक करना टीम को धीमा कर देगा।
• आप एक साफ “किसी ने इसे अपडेट किया” संदेश दिखा सकते हैं।
• आपकी API हर अपडेट पर एक वर्शन (या टाइमस्टैम्प) जाँच सकती है।

यह "चुपचाप ओवरराइट" समस्या को रोकता है। डेटा खोने के बजाय आपको एक साफ़ रोक मिलता है: “इस रिकॉर्ड को आपने खोलने के बाद बदला गया है।”

क्या यह सब कुछ कर सकता है, यह भी मायने रखता है। यह दो लोगों को अलग (पर वैध) निर्णय लेने से नहीं रोकता जो दोनों पुराने जानकारी पर आधारित हैं, और यह स्वतः रूप से बदलावों को मर्ज नहीं करता। और अगर आप चेक सर्वर‑साइड छोड़ देते हैं, तो आप कुछ भी हल नहीं कर रहे।

आम सीमाएँ याद रखें:

• यह conflicts को स्वचालित रूप से हल नहीं करेगा (आपको निर्णय चाहिए)।
• यह तब काम नहीं करेगा जब उपयोगकर्ता ऑफ़लाइन एडिट करके बाद में बिना चेक के सिंक करें।
• यह permissions की गलतियों को ठीक नहीं करेगा (कोई अभी भी गलत जगह एडिट कर सकता है)।
• यह तभी पकड़ता है जब आप सर्वर‑साइड चेक लागू करें, केवल क्लाइंट पर चेक करना पर्याप्त नहीं है।

व्यवहार में, ऑप्टिमिस्टिक लॉकिंग सिर्फ हर एडिट के साथ एक अतिरिक्त वैल्यू भेजने जैसा है, और सर्वर‑साइड पर “only update if it matches” नियम। AppMaster में, यह चेक आमतौर पर बिजनेस लॉजिक में वहीँ रहता है जहाँ अपडेट execute होते हैं।

दो सामान्य तरीके: version कॉलम बनाम updated_at

यह पता लगाने के लिए कि कोई रिकॉर्ड संपादित करते समय बदल गया था, आप आमतौर पर दो संकेतों में से एक चुनते हैं: एक version नंबर या एक updated_at टाइमस्टैम्प।

तरीका 1: Version कॉलम (इन्क्रीमेंटिंग इन्टीजर)

एक version फ़ील्ड जोड़ें (आमतौर पर integer)। जब आप एडिट फॉर्म लोड करते हैं, तो साथ में वर्तमान version भी लोड करें। जब आप सेव करें, तो वही वैल्यू वापस भेजें।

अपडेट केवल तभी सफल होगा जब स्टोर्ड version वही हो जो यूजर ने शुरू में देखा था। अगर मैच होता है, तो रिकॉर्ड अपडेट करें और version को 1 से बढ़ा दें। अगर मैच नहीं होता, तो ओवरराइट करने के बजाय एक conflict लौटाएँ।

यह समझने में आसान है: version 12 का मतलब “यह 12वां बदलाव है।” यह टाइम‑संबंधी किनारों से भी बचता है।

तरीका 2: updated_at (टाइमस्टैम्प तुलना)

ज़्यादातर टेबल्स पहले से updated_at फ़ील्ड रखते हैं। विचार वही है: फॉर्म खुलते समय updated_at पढ़ें, इसे सेव के साथ शामिल करें। सर्वर केवल तभी अपडेट करे जब updated_at अपरिवर्तित हो।

यह अच्छा काम कर सकता है, पर टाइमस्टैम्प में कुछ गोटchas होते हैं। अलग‑अलग डेटाबेस अलग प्रिसिजन स्टोर करते हैं। कुछ सेकंड तक राउंड करते हैं, जिससे तेज़ एडिट मिस हो सकते हैं। यदि कई सिस्टम वही DB लिखते हैं, तो क्लॉक ड्रिफ्ट और टाइमज़ोन हैंडलिंग भी उलझनें पैदा कर सकती हैं।

सरल तुलना:

• Version कॉलम: व्यवहार सबसे स्पष्ट, डेटाबेस-स्वतंत्र, क्लॉक की समस्या नहीं।
• updated_at: अक्सर “फ्री” क्योंकि यह पहले से मौजूद होता है, पर प्रिसिजन और क्लॉक हैंडलिंग में दिक्कतें हो सकती हैं।

अधिकांश टीमों के लिए, version कॉलम प्राथमिक संकेत के रूप में बेहतर है। यह स्पष्ट, पूर्वानुमेय और लॉग/सपोर्ट टिकट्स में संदर्भित करने में आसान है।

अगर आप AppMaster में बना रहे हैं, तो इसका मतलब आमतौर पर Data Designer में integer version फ़ील्ड जोड़ना और यह सुनिश्चित करना है कि आपका अपडेट लॉजिक इसे चेक करे। आप auditing के लिए updated_at रख सकते हैं, पर यह निर्णय लेने के लिए version को ही प्राथमिकता दें।

हर एडिट के साथ क्या स्टोर और क्या भेजें

ऑप्टिमिस्टिक लॉकिंग तभी काम करता है जब हर एडिट के साथ एक "last seen" मार्कर जुड़ा हो जो तब का हो जब यूजर ने फॉर्म खोला था। वह मार्कर version नंबर या updated_at टाइमस्टैम्प हो सकता है। इसके बिना सर्वर यह नहीं बता सकता कि रिकॉर्ड के बीच में बदलाव हुए थे या नहीं।

रिकॉर्ड पर, अपने सामान्य बिजनेस फ़ील्ड्स के साथ एक concurrency फ़ील्ड रखें जिसे सर्वर नियंत्रित करे। न्यूनतम सेट दिखता है:

• id (स्थायी पहचान)
• बिजनेस फ़ील्ड्स (name, status, price, notes, आदि)
• version (प्रत्येक सफल अपडेट पर इनक्रीमेंट होने वाला integer) या updated_at (सर्वर-द्वारा लिखित टाइमस्टैम्प)

जब एडिट स्क्रीन लोड हो, तो फॉर्म को उस concurrency फ़ील्ड की last-seen वैल्यू स्टोर करनी चाहिए। उपयोगकर्ता इसे एडिट न करें — इसे hidden फ़ील्ड या फॉर्म स्टेट में रखें। उदाहरण: API version: 12 लौटाती है, और फॉर्म उस 12 को तब तक रखे जब तक Save न हो।

जब यूजर Save पर क्लिक करे, तो दो चीज़ें भेजें: बदलाव और last-seen मार्कर। सबसे सरल रूप में अपडेट रिक्वेस्ट बॉडी में id, बदले हुए फ़ील्ड्स और expected_version (या expected_updated_at) शामिल करें। AppMaster में UI बनाते समय इसे किसी अन्य बाउंड वैल्यू की तरह ट्रीट करें: रिकॉर्ड के साथ लोड करें, अपरिवर्तित रखें, और अपडेट के साथ सबमिट करें।

सर्वर पर, अपडेट conditional होना चाहिए। आप केवल तभी अपडेट करें जब expected मार्कर वर्तमान DB वैल्यू से मैच करे। अगर मैच नहीं करता, तो चुपचाप मर्ज न करें।

एक conflict response स्पष्ट और UI के लिए हैंडल करने योग्य होना चाहिए। एक व्यावहारिक conflict response में होना चाहिए:

• HTTP status 409 Conflict
• छोटा संदेश जैसे “This record was updated by someone else.”
• वर्तमान सर्वर वैल्यू (current_version या current_updated_at)
• वैकल्पिक रूप से, वर्तमान सर्वर रिकॉर्ड (ताकि UI दिखा सके क्या बदला)

उदाहरण: सम एक Customer रिकॉर्ड version: 12 पर खोलता है। प्रिया एक बदलाव सेव करती है, जो इसे version 13 बनाती है। बाद में सम Save करता है with expected_version: 12। सर्वर 409 के साथ current record version 13 लौटाता है। अब UI सम को नवीनतम मानों की समीक्षा करने के लिए कह सकता है बजाय प्रिया के एडिट को ओवरराइट करने के।

चरण-दर-चरण: एंड‑टू‑एंड ऑप्टिमिस्टिक लॉकिंग लागू करें

ऑप्टिमिस्टिक लॉकिंग मूलतः एक नियम पर आता है: हर एडिट को यह सिद्ध करना चाहिए कि वह रिकॉर्ड के नवीनतम सेव्ड संस्करण पर आधारित है।

1) एक concurrency फ़ील्ड जोड़ें

एक ऐसा फ़ील्ड चुनें जो हर लिखने पर बदल जाए।

एक समर्पित integer version सबसे आसान है। 1 से शुरू करें और हर अपडेट पर 1 बढ़ाएँ। यदि आपके पास पहले से भरोसेमंद updated_at टाइमस्टैम्प है जो हर लिखने पर बदलता है, तो आप उसका उपयोग कर सकते हैं, पर सुनिश्चित करें कि वह प्रत्येक write (background jobs सहित) पर अपडेट हो।

2) पढ़ने पर वह मान क्लाइंट को भेजें

जब UI एडिट स्क्रीन खोलती है, तो response में वर्तमान version (या updated_at) शामिल करें। इसे फॉर्म स्टेट में hidden वैल्यू के रूप में रखें।

इसे एक रिसीट की तरह सोचें जो कहती है: “मैं वही एडिट कर रहा हूँ जो मैंने आख़िरी बार पढ़ा था।”

3) अपडेट पर वह वैल्यू अनिवार्य करें

सेव पर, क्लाइंट बदले हुए फ़ील्ड्स और last-seen concurrency वैल्यू दोनों भेजे।

सर्वर पर, अपडेट conditional रखें। SQL के संदर्भ में, यह कुछ ऐसा होता है:

UPDATE tickets
SET status = $1,
    version = version + 1
WHERE id = $2
  AND version = $3;

यदि अपडेट 1 row को प्रभावित करता है, तो सेव सफल रही। यदि 0 rows प्रभावित होती हैं, तो किसी और ने पहले से रिकॉर्ड बदल दिया है।

4) सफलता के बाद नया मान लौटाएँ

सफल सेव के बाद, अपडेटेड रिकॉर्ड नया version (या नया updated_at) के साथ लौटाएँ। क्लाइंट को फॉर्म स्टेट उसी से बदलना चाहिए। यह पुराने version से दोबारा सेव होने से बचाता है।

5) कन्फ्लिक्ट्स को सामान्य परिणाम मानें

जब conditional update फेल करे, तो एक स्पष्ट conflict response लौटाएँ (अक्सर HTTP 409) जो शामिल करे:

• अब जैसा है वैसा current सर्वर रिकॉर्ड
• क्लाइंट के प्रयास किए गए परिवर्तन (या इतना कि UI उन्हें पुनर्निर्मित कर सके)
• यदि संभव हो तो कौन से फ़ील्ड अलग हैं (यदि आप यह गणना कर सकते हैं)

AppMaster में, यह PostgreSQL मॉडल फ़ील्ड, एक रीड एंडपॉइंट जो version लौटाता है, और एक Business Process जो conditional update करता है और success या conflict हैंडलिंग में ब्रांच करता है, के रूप में अच्छा फ़िट बैठता है।

यूआई पैटर्न जो कन्फ्लिक्ट्स को उपयोगकर्ता के लिए कष्टप्रद नहीं बनाते

ऑप्टिमिस्टिक लॉकिंग आधा काम है। दूसरा आधा वह है जो उपयोगकर्ता देखता है जब उनकी सेव किसी और के बदलाव के कारण reject होती है।

अच्छी conflict UI के दो लक्ष्य होते हैं: चुपचाप ओवरराइट रोकना, और उपयोगकर्ता को जल्दी अपना काम पूरा करने में मदद करना। अच्छी तरह किया जाए तो यह एक सहायक गार्डरेल लगता है, रोडब्लॉक नहीं।

पैटर्न 1: साधारण blocking डायलॉग (सबसे तेज़)

जब एडिट छोटे हों और उपयोगकर्ता reload करके आसानी से अपना बदलाव फिर से लगा सकें तो यह प्रयोग करें।

संदेश छोटा और विशिष्ट रखें: “यह रिकॉर्ड आपके एडिट के दौरान बदल गया है। नवीनतम देखने के लिए reload करें।” फिर दो साफ क्रियाएँ दें:

• Reload and continue (primary)
• Copy my changes (वैकल्पिक पर उपयोगी)

“Copy my changes” unsaved मानों को clipboard पर रख सकता है या reload के बाद फॉर्म में बनाए रख सकता है ताकि लोग जो टाइप किया उसे याद न रखें।

यह सिंगल‑फील्ड अपडेट्स, टॉगल्स, स्टेटस चेंज या छोटे नोट्स के लिए अच्छा है। अधिकांश बिल्डरों (AppMaster सहित) में इसे लागू करना भी आसान है।

पैटर्न 2: “Review changes” (महत्वपूर्ण रिकॉर्ड्स के लिए सबसे अच्छा)

जब रिकॉर्ड महत्वपूर्ण हो (प्राइसिंग, परमिशन, पेआउट, अकाउंट सेटिंग्स) या फॉर्म लंबा हो, तो उपयोगकर्ता को एक conflict स्क्रीन पर भेजें जो तुलना दिखाता है:

• “Your edits” (आपने जो सेव करने की कोशिश की)
• “Current values” (डेटाबेस का नवीनतम)
• “What changed since you opened it” (सिर्फ़ conflicting फ़ील्ड्स)

फोकस्ड रखें — अगर सिर्फ तीन फ़ील्ड कन्फ्लिक्ट में हैं तो हर फ़ील्ड न दिखाएँ।

प्रत्येक conflicting फ़ील्ड के लिए सरल विकल्प दें:

• मेरी वाली रखें
• उनकी वाली लें
• मर्ज करें (जब समझ में आए, जैसे टैग्स या नोट्स)

कन्फ्लिक्ट्स रेशोल्व करने के बाद, सबसे नवीनतम वर्शन वैल्यू के साथ फिर से सेव करें। रिच टेक्स्ट या लंबे नोट्स के लिए छोटा diff दिखाएँ ताकि उपयोगकर्ता जल्दी निर्णय ले सकें।

कब फोर्स्ड ओवरराइट की अनुमति दें (और किसे)

कभी-कभी फोर्स्ड ओवरराइट ज़रूरी होता है, पर यह दुर्लभ और नियंत्रित होना चाहिए। यदि आप इसे जोड़ें, तो इसे सचेत बनाइए: एक संक्षिप्त कारण माँगे, किसने किया लॉग करें, और अनुमति केवल admin/supervisor जैसे रोल्स तक सीमित रखें।

नियमित उपयोगकर्ताओं के लिए डिफॉल्ट “Review changes” रखें। जब उपयोगकर्ता रिकॉर्ड मालिक हो, रिकॉर्ड कम‑जोखिम वाला हो, या सिस्टम निगरानी में खराब डेटा सही कर रहा हो तब ही फोर्स्ड ओवरराइट तर्कसंगत होता है।

उदाहरण परिदृश्य: दो सहकर्मी एक ही रिकॉर्ड एडिट करते हैं

दो सपोर्ट एजेंट, Maya और Jordan, एक ही ग्राहक प्रोफ़ाइल पर काम कर रहे हैं। दोनों खोलते हैं, अलग कॉल्स के बाद स्टेटस और नोट्स अपडेट करते हैं।

टाइमलाइन (ऑप्टिमिस्टिक लॉकिंग सक्षम, version या updated_at चेक के साथ):

• 10:02 - Maya Customer #4821 खोलती है। फॉर्म लोड होता है Status = "Needs follow-up", Notes = "Called yesterday" और Version = 7.
• 10:03 - Jordan भी वही रिकॉर्ड खोलता है; उसे भी Version = 7 दिखता है।
• 10:05 - Maya Status को "Resolved" करती है और नोट जोड़ती है: "Issue fixed, confirmed by customer." वह Save करती है।
• 10:05 - सर्वर रिकॉर्ड अपडेट करता है, Version को 8 कर देता है (या updated_at अपडेट करता है), और audit entry बनाता है: किसने क्या और कब बदला।
• 10:09 - Jordan अलग नोट टाइप करता है: "Customer asked for a receipt" और Save करता है।

बिना concurrency चेक के, Jordan की सेव Maya के स्टेटस और नोट को चुपचाप ओवरराइट कर सकती थी। ऑप्टिमिस्टिक लॉकिंग से सर्वर Jordan की अपडेट को reject कर देगा क्योंकि वह Version = 7 के साथ सेव कर रहा था जबकि रिकॉर्ड अब Version = 8 पर है।

Jordan को एक साफ़ कन्फ्लिक्ट संदेश दिखता है और UI उसे सुरक्षित अगला कदम देता है:

• नवीनतम रिकॉर्ड reload करें (मेरे एडिट्स छोड़ दें)
• मेरी बदलें नवीनतम पर लागू करें (जहाँ संभव हो)
• अंतर देखें ("Mine" vs "Latest") और चुनें क्या रखें

एक सरल स्क्रीन दिखा सकती है:

• “यह ग्राहक Maya ने 10:05 पर अपडेट किया”
• जिन फ़ील्ड्स में बदलाव हुआ उन्हें हाइलाइट करें (Status और Notes)
• Jordan के unsaved नोट का preview दिखाएँ ताकि वह उसे कॉपी या फिर से लागू कर सके

Jordan “Review differences” चुनता है, Maya का Status = "Resolved" रखता है, और अपना नोट मौजूदा नोट के अंत में जोड़ देता है। वह फिर से Save करता है, अब Version = 8 के साथ, और अपडेट सफल हो जाता है (अब Version = 9)।

अंतिम स्थिति: कोई डेटा लॉस नहीं, यह नहीं पता लगना कि किसने किसे ओवरराइट किया, और एक साफ audit trail जो Maya के स्टेटस परिवर्तन और दोनों नोट्स को ट्रेस करता है। AppMaster में यह एक conditional update और एक छोटा conflict-resolution डायलॉग से आसानी से मैप होता है।

आम गलतियाँ जो अभी भी डेटा लॉस कराती हैं

ज़्यादातर "ऑप्टिमिस्टिक लॉकिंग" बग्स विचार के बारे में नहीं होते; वे UI, API और DB के बीच के हस्तांतरण में होते हैं। यदि किसी एक लेयर ने नियम भूल गया, तो फिर भी साइलेंट ओवरराइट हो सकती है।

एक क्लासिक गलती यह है कि एडिट स्क्रीन लोड करते वक्त version (या timestamp) लिया जाता है, पर सेव पर उसे वापस नहीं भेजा जाता। यह अक्सर तब होता है जब एक फॉर्म कई जगहों पर reuse होता है और hidden फ़ील्ड छूट जाता है, या जब API क्लाइंट केवल “changed” फ़ील्ड्स भेजता है।

एक और जाल केवल ब्राउज़र में चेक करना है। उपयोगकर्ता को चेतावनी दिखती है, पर अगर सर्वर अपडेट स्वीकार कर लेता है, तो कोई दूसरा क्लाइंट (या retry) डेटा चुपचाप ओवरराइट कर सकता है। सर्वर को अंतिम गेटकीपर होना चाहिए।

सबसे data-loss पैदा करने वाले पैटर्न:

• सेव रिक्वेस्ट में concurrency token नहीं भेजना (version, updated_at, या ETag) — सर्वर के पास तुलना करने के लिए कुछ नहीं होता।
• केवल id से अपडेट स्वीकार करना बजाय “id + version” के एटॉमिक कंडीशन के।
• सेकंड‑लेवल पर स्टोर किए गए updated_at जैसी कम प्रिसिजन वाली timestamps का उपयोग।
• बड़े फ़ील्ड्स (notes, descriptions) या पूरे ऐरे (tags, line items) को बिना यह दिखाए रिप्लेस करना कि क्या बदला — इससे दूसरों के बदलाव मिट सकते हैं।
• किसी भी कन्फ्लिक्ट को सिर्फ़ “फिर से कोशिश करो” मान लेना, जो stale वैल्यूज़ को नवीनतम डेटा पर फिर से लागू कर सकता है।

एक ठोस उदाहरण: दो सपोर्ट लीड एक ही ग्राहक रिकॉर्ड खोलते हैं। एक लंबा इंटरनल नोट जोड़ता है, दूसरा स्टेटस बदलता है और सेव करता है। अगर आपका सेव पूरा रिकॉर्ड payload से रिप्लेस कर देता है, तो स्टेटस बदलाव नोट को मिटा सकता है।

जब कन्फ्लिक्ट होता है, टीमें तब भी डेटा खो देती हैं अगर API response पर्याप्त नहीं है। सिर्फ़ "409 Conflict" लौटाने के बजाय पर्याप्त जानकारी लौटाएँ:

• current server version (या updated_at)
• संबंधित फ़ील्ड्स के नवीनतम सर्वर मान
• वे फ़ील्ड जिनमें फर्क है (सरल नाम भी ठीक है)
• किसने और कब बदला (यदि आप इसे ट्रैक करते हैं)

AppMaster में लागू करने के लिए वही अनुशासन अपनाएँ: UI स्टेट में version रखें, update के साथ भेजें, और पोस्टग्रेSQL में लिखने से पहले बैकएंड लॉजिक में चेक लागू करें।

शिप करने से पहले त्वरित चेक

रोलआउट से पहले उन failure modes की एक छोटी जाँच करें जो “इसे ठीक से सेव कर दिया” जैसा दिखाते हुए किसी और के काम को चुपचाप ओवरराइट कर देते हैं।

डेटा और API चेक

सुनिश्चित करें कि रिकॉर्ड end-to-end एक concurrency token ले जाता है — वह version integer हो या updated_at timestamp, पर उसे रिकॉर्ड का हिस्सा मानें, न कि वैकल्पिक मेटाडाटा।

• Reads में टोकन शामिल हो और UI उसे फॉर्म स्टेट में स्टोर करे (सिर्फ स्क्रीन पर न)।
• हर अपडेट last-seen टोकन वापस भेजता है, और सर्वर लिखने से पहले उसे सत्यापित करता है।
• सफलता पर सर्वर नया टोकन लौटाता है ताकि UI sync में रहे।
• bulk edits और inline edits भी वही नियम अपनाएँ, कोई शॉर्टकट न बनाएं।
• बैकग्राउंड जॉब जो उन्हीं rows को एडिट करते हैं वे भी चेक करें (नहीं तो उनके कारण यादृच्छिक कन्फ्लिक्ट होंगे)।

AppMaster में, यह सुनिश्चित करें कि Data Designer में फ़ील्ड मौजूद है (version या updated_at), और Business Process update फ्लो में उसे तुलना के लिए रखें।

UI चेक

एक कन्फ्लिक्ट तब ही “सुरक्षित” माना जा सकता है जब अगला कदम स्पष्ट हो।

जब सर्वर अपडेट reject करे तो एक साफ संदेश दिखाएँ: “यह रिकॉर्ड तब से बदल गया जब आपने इसे खोला था।” फिर एक सुरक्षित कार्रवाई पहले दें: नवीनतम डेटा reload करें। यदि संभव हो तो “reload and reapply” पाथ जोड़ें जो उपयोगकर्ता के unsaved इनपुट को रखे और उन्हें ताज़ा रिकॉर्ड पर दोबारा लागू करे, ताकि छोटा संशोधन फिर से टाइप करना न पड़े।

यदि टीम को सच में ज़रूरी हो तो नियंत्रित “force save” विकल्प दें। इसे रोल से गेट करें, कन्फर्म कराएँ, और लॉग करें कि किसने फोर्स किया और क्या बदला। इससे आप इमरजेंसी की अनुमति देते हैं बिना डेटा लॉस को डिफ़ॉल्ट बनाए।

अगले कदम: एक वर्कफ़्लो पर लॉकिंग जोड़ें और विस्तार करें

छोटी शुरुआत करें। किसी एक एडमिन स्क्रीन को चुनें जहाँ लोग अक्सर एक‑दूसरे से टकराते हों, और पहले वहीँ optimistic locking जोड़ें। हाई‑कोलिशन क्षेत्र आमतौर पर टिकट्स, ऑर्डर्स, प्राइसिंग और इन्वेंट्री होते हैं। एक व्यस्त स्क्रीन पर कन्फ्लिक्ट्स को सुरक्षित बनाने के बाद आप पैटर्न को बाकी स्क्रीन पर जल्दी दोहरा पाएँगे।

पहले से अपने डिफ़ॉल्ट कन्फ्लिक्ट व्यवहार का चुनाव करें, क्योंकि यह बैकएंड लॉजिक और UI दोनों को आकार देता है:

• Block-and-reload: सेव रोकें, नवीनतम रिकॉर्ड reload करें, और उपयोगकर्ता से फिर से लागू करने को कहें।
• Review-and-merge: “आपके बदलाव” बनाम “नवीनतम बदलाव” दिखाएँ और उपयोगकर्ता तय करे क्या रखना है।

Block-and-reload जल्दी बनाने के लिए तेज़ है और छोटे एडिट्स (स्टेटस, असाइनमेंट, छोटे नोट्स) में अच्छा काम करता है। Review-and-merge लंबी या हाई‑स्टेक रिकॉर्ड्स (प्राइसिंग टेबल्स, मल्टि‑फील्ड ऑर्डर एडिट्स) के लिए सही है।

फिर एक पूरा फ्लो टेस्ट करके ही विस्तार करें:

• एक स्क्रीन चुनें और उन फ़ील्ड्स की सूची बनाएं जिन्हें उपयोगकर्ता सबसे ज़्यादा बदलते हैं।
• फॉर्म पेलोड में version (या updated_at) जोड़ें और सेव पर उसे अनिवार्य करें।
• DB write में conditional update लागू करें (सिर्फ तब अपडेट करें जब version मैच करे)।
• कन्फ्लिक्ट संदेश और अगला कदम डिजाइन करें (reload, copy मेरा टेक्स्ट, compare view)।
• दो ब्राउज़रों से टेस्ट करें: टैब A में सेव करें, फिर टैब B में stale डेटा सेव करने की कोशिश करें।

कन्फ्लिक्ट्स के लिए हल्का‑फुल्का लॉगिंग जोड़ें। एक सरल “conflict हुआ” इवेंट जिसमें record प्रकार, स्क्रीन नाम और user role हो, यह आपको hotpots दिखाने में मदद करेगा।

यदि आप AppMaster (appmaster.io) से एडमिन टूल बनाते हैं, तो मुख्य हिस्से साफ तरह से मैप होते हैं: Data Designer में version फ़ील्ड मॉडल करें, Business Processes में conditional updates लागू करें, और UI बिल्डर में एक छोटा conflict डायलॉग जोड़ें। एक बार पहला वर्कफ़्लो स्थिर हो जाए, वही पैटर्न स्क्रीन दर स्क्रीन दोहराएँ और conflict UI को स्थिर रखें ताकि उपयोगकर्ता इसे एक बार सीखकर हर जगह भरोसा कर सकें।