అందరూ రియల్-టైమ్ అప్‌డేట్‌లను కోరుకుంటారు, కానీ "వేగం" (fast) మరియు "ఖచ్చితత్వం" (correct) ఒకటి కాదని తెలిసినప్పుడు పరిస్థితి మారుతుంది. ఒక డిస్ట్రిబ్యూటెడ్ సిస్టమ్‌లో, ఈవెంట్‌లు కాంతి వేగంతో ప్రయాణించినప్పటికీ, అవి తప్పు క్రమంలో చేరుకోవచ్చు. WebSockets డిస్‌కనెక్ట్ అయ్యి మళ్ళీ కనెక్ట్ కావచ్చు. మెసేజ్ బ్రోకర్లు ప్యాకెట్‌లను మళ్ళీ పంపవచ్చు (redeliver). బ్యాక్‌గ్రౌండ్ వర్కర్లు టైమ్-అవుట్ క్యాన్సిలేషన్స్‌తో పోటీ పడాల్సి వస్తుంది. దీని ఫలితం? ఒక క్లయింట్ ఈవెంట్ 42ని చూసి, ఆ తర్వాత ఈవెంట్ 40ని, ఆపై సిస్టమ్ ఇప్పటికే ఈవెంట్ 45 వద్ద ఉందని చెప్పే స్నాప్‌షాట్‌ని చూడవచ్చు. మీరు లాంగ్-రన్నింగ్ ఏజెంట్ వర్క్‌ఫ్లోలను నిర్మిస్తుంటే, ఈ గందరగోళం కేవలం అరుదైన సందర్భం (edge case) కాదు. అది ఒక ప్రాథమిక సమస్య (baseline). డెలివరీ సమయాన్ని తగ్గించడం గురించి ఆలోచించే ముందు, మీ ఈవెంట్‌ల క్రమాన్ని సరిచేయండి.

'రియల్-టైమ్' యొక్క గందరగోళ వాస్తవికత

రియల్-టైమ్ అనేది ఒక ట్రాన్స్‌పోర్ట్ ప్రాపర్టీ. ఇది ఒక ప్యాకెట్ వైర్ ద్వారా ఎంత వేగంగా కదులుతుందో వివరిస్తుంది కానీ, అది చెప్పే కథ అర్థవంతంగా ఉందో లేదో చెప్పదు. లాంగ్-రన్నింగ్ టాస్క్‌లు ప్రతి అసమతుల్యతను (inconsistency) పెంచుతాయి ఎందుకంటే అవి ఎక్కువ సమయం పాటు కొనసాగుతాయి. ఒక మోడల్ ట్రైనింగ్ జాబ్, మల్టీ-స్టెప్ అప్రూవల్ ఫ్లో, లేదా వీడియో రెండరింగ్ పైప్‌లైన్ నిమిషాలు లేదా గంటల వ్యవధిలో డజన్ల కొద్దీ ఈవెంట్‌లను విడుదల చేయవచ్చు. ఆ సమయంలో, ఏదైనా తప్పు జరగవచ్చు.

ఒక అక్నాలెడ్జ్‌మెంట్ (acknowledgement) పోయినందున బ్రోకర్ ఒక మెసేజ్‌ను మళ్ళీ ప్రయత్నించవచ్చు. ఒక లోడ్ బ్యాలెన్సర్ రెండు ఈవెంట్‌లను వేర్వేరు నెట్‌వర్క్ మార్గాల ద్వారా పంపిస్తే, కొత్తది ముందుగా వచ్చే అవకాశం ఉంది. ఒక వర్కర్ ప్రాసెస్ డేటాబేస్‌లో రాసిన తర్వాత కానీ, సక్సెస్ ఈవెంట్‌ను పబ్లిష్ చేయకముందే కానీ ఆగిపోవచ్చు, అప్పుడు రెండో వర్కర్ ఆ టాస్క్‌ను తీసుకుని తన స్వంత ప్రోగ్రెస్ ఈవెంట్‌ను పంపవచ్చు. మీ ఫ్రంటెండ్ తాజా మెసేజ్ మాత్రమే నిజమైన మెసేజ్ అని అనుకుంటే, అది అసలు లేని ఒక స్టేట్‌ను చూపిస్తుంది. వినియోగదారులు 'completed' బ్యాడ్జ్ మళ్ళీ 'processing' కి మారడం చూడవచ్చు, లేదా ఇంకా దారుణంగా, క్యాన్సిల్ చేయబడిన టాస్క్ అకస్మాత్తుగా మళ్ళీ మొదలవ్వడం చూడవచ్చు. క్రమం (ordering) లేని వేగం అనేది కేవలం అధిక ఫ్రేమ్ రేట్‌తో కూడిన గందరగోళం మాత్రమే.

సీక్వెన్స్ నంబర్లే అసలైన క్లాక్

దీనికి పరిష్కారం ప్రొడ్యూసర్ ద్వారా సృష్టించబడే కచ్చితమైన, మోనోటోనిక్ సీక్వెన్స్ నంబర్లు (strict, monotonic sequence numbers). స్టేట్‌ను మార్చే ప్రతి ఆపరేషన్‌కు ఖచ్చితంగా ఒకటి పెరిగేలా, ఎటువంటి గ్యాప్‌లు లేదా రోల్‌బ్యాక్‌లు లేకుండా ఒక నంబర్ కేటాయించబడాలి. ఆ నంబర్ ఈవెంట్‌తో పాటు అదే ట్రాన్సాక్షన్‌లో నిక్షిప్తం (persist) చేయబడాలి. డేటాబేస్ రో అప్‌డేట్ అయ్యి, సీక్వెన్స్ కమిట్ విఫలమైతే, మీరు రెండింటినీ రోల్‌బ్యాక్ చేయాలి. ఇది లాజికల్ టైమ్‌లైన్‌ను స్టేట్ చేంజ్‌తో కలిపి అటామిక్‌గా ఉంచుతుంది.

ఈవెంట్ ఐడిలు (Event IDs) ఇప్పటికీ ఉపయోగకరమే, కానీ అవి వేరే సమస్యను పరిష్కరిస్తాయి. బ్రోకర్ ఒకే మెసేజ్‌ను రెండుసార్లు పంపినప్పుడు, డూప్లికేట్‌లను తొలగించడానికి ఈవెంట్ ఐడి ఒక నిర్దిష్ట పేలోడ్‌ను గుర్తిస్తుంది. మరోవైపు, సీక్వెన్స్ నంబర్ ఆ పేలోడ్ కారణాధార గొలుసులో (causal chain) ఎక్కడ ఉండాలో చెబుతుంది. ఇది గ్యాప్‌లను మరియు క్రమాన్ని బయటపెడుతుంది. టైమ్‌స్టాంప్ (Timestamp) ఈ రెండింటినీ చేయలేదు. క్లాక్‌లు డ్రిఫ్ట్ అవుతాయి, NTP వెనక్కి వెళ్తుంది, మరియు వర్చువల్ మెషీన్‌లు పాజ్ అవుతాయి. టైమ్‌స్టాంప్‌లను కేవలం ప్రదర్శన కోసం మాత్రమే ఉపయోగించండి, ఉదాహరణకు "3 నిమిషాల క్రితం ప్రారంభమైంది" వంటి వాటి కోసం, కానీ బిజినెస్ లాజిక్ కోసం సార్టింగ్ కీగా ఎప్పుడూ ఉపయోగించకండి.

క్లయింట్ స్ట్రీమ్‌ను ఎలా హ్యాండిల్ చేయాలి

ప్రొడ్యూసర్ ఒక మోనోటోనిక్ సీక్వెన్స్‌ను గ్యారెంటీ ఇచ్చిన తర్వాత, కన్స్యూమర్‌కు సరళమైన, కఠినమైన నియమాలు అందుతాయి. ఒక ఇన్బౌండ్ సీక్వెన్స్ నంబర్ చివరిసారిగా అప్లై చేసిన నంబర్ కంటే తక్కువ లేదా సమానంగా ఉంటే, దానిని వదిలేయండి (drop). అది డూప్లికేట్ కావచ్చు లేదా పాతది కావచ్చు. సీక్వెన్స్ నంబర్ చివరిసారిగా అప్లై చేసిన నంబర్ కంటే సరిగ్గా ఒకటి ఎక్కువగా ఉంటే, దానిని వెంటనే అప్లై చేయండి. అదే సరైన మార్గం (happy path). ఒకవేళ సీక్వెన్స్ దూకితే, అంటే మీరు 12ని ఆశించి 15ని అందుకుంటే, ఏదో ఒకటి మిస్ అయిందని అర్థం. కొత్త ఈవెంట్‌ను బఫర్ చేయండి మరియు తదుపరి ఆశించిన సీక్వెన్స్ నుండి రీప్లే కోసం సర్వర్‌ను అడగండి. ఊహించకండి. గ్యాప్ ముఖ్యం కాదు అని ఆశించి ముందుకు వెళ్లకండి.

టెర్మినల్ స్టేట్‌లను (Terminal states) మార్చలేనివిగా పరిగణించాలి. ఒక టాస్క్ 'completed', 'failed', లేదా 'cancelled' అని మార్క్ చేయబడిన తర్వాత, ఆ ఆపరేషన్ కోసం తదుపరి స్టేట్ మార్పులను క్లయింట్ తిరస్కరించాలి. మీరు దీనిని ఎదుర్కొనే వరకు ఇది చాలా స్పష్టంగా అనిపిస్తుంది