Чаттар мен формалардағы қайталанған сұраныстарды UX-ке зиян келтірмей дедупликациялау

Неліктен қосарланған жіберулер пайда болады

Қайта жіберу көбіне "ұқыпсыз пайдаланушыдан" емес, интерфейс, желі және сервер бөлігінің қалыпты жұмысынан пайда болады. Адам батырманы бір рет басты, бір секунд ішінде жауап көрмеді де, қайта басты. Жүйе де дәл солай істейді: клиент, мобильді қосымша немесе кезек сұранысты автоматты түрде қайталауы мүмкін.

Ең жиі себеп - үнсіз интерфейс. Батырма күйін өзгертпейді, жүктелу индикаторы шықпайды, чаттағы хабарлама бірден көрінбейді. Пайдаланушы бос экранды көріп, тағы бір рет басады. Оның көзінде бұл - әрекетті аяқтаудың бір ғана талпынысы. Сервер үшін - екі талпыныс.

Екінші жиі себеп - таймаут. Клиент сұранысты жіберді, сервер өңдеуді бастады, бірақ жауап уақытында оралмады. Қосымша сұраныс "жоғалды" деп ойлап, оны қайта жібереді. Мәселе мынада: сол сәтке қарай алғашқы сұраныс жазба жасап, хат жіберіп немесе чаттағы хабарламаны сақтап үлгеруі мүмкін. Екіншісі бірнеше секундтан кейін келіп, дәл сол әрекетті тағы бір рет орындайды.

Мобильді желіде бұл одан да жиі болады. Қосылу жауап келгенге дейін емес, деректер жіберілгеннен кейін үзілуі мүмкін. Телефон Wi-Fi мен LTE арасында ауысады, қосымша сессияны қалпына келтіреді де, сол пакетті қайта жібереді. Пайдаланушы бір ғана әрекетті көреді, ал сізде бір-біріне ұқсас екі сұраныс пайда болады.

Кезек пен worker-ларда да жағдай ұқсас. Көптеген кезектер "кемінде бір рет жеткіземіз" деген қағидамен жұмыс істейді. Егер worker оқиғаны өңдеп, бірақ апат алдында оны растай алмаса, кезек сол оқиғаны қайта береді. Осылайша кезектен келетін қайталаулар пайда болады: тапсырманың екінші рет іске қосылуы, қайта есептен шығару, хабарламаның дубликаты немесе диалогтағы тағы бір хабар.

Кейде қайталанудың көзі бірден байқалмайды. Бір форма вебтен және мобильді клиенттен бір уақытта дерлік кетуі мүмкін. Чат хабарламаны жергілікті түрде жіберіп, кейін қайта қосылған соң оны тағы қайталауы мүмкін. Қайталанған сұраныстарды дедупликациялау болмаса, мұндай жағдайлар "сирек оғаштық" сияқты көрінеді. Шын мәнінде бұл - сенімсіз желі мен бөлінген жүйедегі жұмыстың қалыпты құны.

Ереже қарапайым: егер әрекет батырма, желі немесе кезек арқылы өтсе, қайталау ерте ме, кеш пе пайда болады.

Бұл қайталау ма, әлде жаңа әрекет пе - қалай түсінуге болады

Қайталану ешқашан дерлік дәл көшірме болып көрінбейді. Уақыты, талпыныс нөмірі, желілік тақырып немесе техникалық trace id өзгеше болуы мүмкін. Мұндай өрістерді салыстыру көп пайда бермейді. Іздеу керек нәрсе - пайдаланушының өз әрекеті.

Ең сенімді жол - әр әрекетке id-ді клиент жағында бірден беру. Пайдаланушы "Жіберу" батырмасын бір рет басты, ал қосымша сол сәтте action_id жасады. Егер желі кідірсе, мобильді клиент сұранысты қайта жіберсе немесе кезек оны тағы берсе, сол action_id бүкіл тізбек бойымен әрі қарай жүреді. Сонда сервер "тағы бір ұқсас сұранысты" емес, сол бір әрекетті көреді.

Егер клиент кейде сол id-ді жоғалтып алса немесе қайталау кезінде жаңасын жасаса, бір id жеткіліксіз. Сондықтан сұраныстың мағынасын да салыстырған дұрыс. Әдетте әрекет авторын, адресатын немесе объектіні, сұраныс мазмұнын және бұл орын алған экранды қарау жеткілікті.

Чаттарда қайталау терезесі көбіне қысқа болады. Егер бір пайдаланушы бір диалогқа бірдей хабарламаны 5-10 секунд ішінде жіберсе, бұл көбіне нашар желіден немесе екі рет басудан туған дубликат. Бірақ бірнеше минуттан кейін бұл әдейі қайталау болуы мүмкін. Формаларда бұл терезе жиі ұзағырақ. Несие өтінімі, төлем немесе тапсырыс ұзақ жүктелгеннен кейін батырма қайта басылғанда бір минуттан да, он минуттан да кейін қайтып келуі мүмкін.

Сондықтан дедупликация терезесін әрекет түріне қарай бөлек сақтау жақсы. Чат үшін жылдамдық пен жұмсақ мінез-құлық маңызды. Формалар үшін екінші рет есептен шығару, екінші тапсырыс немесе екінші тіркеуден қорғау маңызды. Барлық сценарийге ортақ бір ереже көбіне UX-ті немесе бизнес-логиканы бұзады.

Егер сервер сол action_id-ді таныса, жаңа қате қайтарудың қажеті жоқ. Оның орнына бұрынғы нәтижені берген дұрыс. Пайдаланушы үшін бұл тыныш көрінеді: хабарлама әлдеқашан жіберілген, форма қабылданған, тапсырма құрылған. Мұндай жауап артық уайымды алып тастайды және әрекет сәтті болды ма, жоқ па деген күмән қалдырмайды.

Жұмыс істейтін схема былай көрінеді: клиент id жасайды, сервер оны нәтижемен бірге сақтайды, ал қайталаған сұраныс сол жауапты алады. Дәл осылай сұраныстардың идемпотенттілігі қосарланған формаларды және чаттағы қайталанған хабарламаларды жаңа әрекеттен ажыратуға көмектеседі, тіпті кезектен келген қайталаулар кешігіп, басқа ретпен келсе де.

UX-ті бұзбай қалай қорғануға болады

Адам "Жіберу" батырмасын екінші рет басқанда, дубликат жасағысы келмейді. Әдетте интерфейс тым ұзақ үндемей қояды. Пайдаланушы үшін үнсіздік - ақау сияқты. Сондықтан қайталанған сұраныстарды дедупликациялау түсінікті кері байланыспен бірге жүруі керек.

Жіберу батырмасын басқаннан кейін бірден бұғаттаған дұрыс, бірақ ұзаққа емес. Көбіне бірнеше секунд немесе серверден алғашқы жауапты күту жеткілікті. Егер желі одан ұзақ кідірсе, батырманы қайта ашып, не болып жатқанын көрсетіңіз. Мәңгі қатып қалған батырма сирек болатын қосарланған жіберуден де көбірек ашуландырады.

Адам нені көруі керек

Жібергеннен кейін экран сұраныстың күйін қарапайым сөзбен түсіндіруі керек. Көбіне мынадай хабарламалар жеткілікті:

• "Жіберіп жатырмыз..."
• "Сұраныс қабылданды, жауап күтеміз"
• "Байланыс үзілді. Қайталау керек пе?"
• "Бұл сұранысты біз бұрыннан алдық"

Соңғысы мобильді желі жиі құбылатын жерде әсіресе пайдалы. Егер сервер алғашқы сұранысты қабылдап қойған болса, екіншісі жаңа қате сияқты көрінбеуі керек. Жүйе қайталауды танып, дубликат жасамағанын бірден көрсеткені жақсы. Чатта бұл - бір ғана хабарлама көпіршігі және жеткізу статусы, қатар тұрған екі бірдей хабарлама емес.

Жобаны қорғауда draft та көп көмектеседі. Егер адам чатта ұзақ мәтін терсе немесе форманы толтырып, байланыс үзілсе, бәрін қайта бастатпаңыз. Маңызды өзгерістерден кейін мәтінді жергілікті түрде сақтап отырыңыз. Форма үшін әдетте өрістер мен тіркемелерді сақтау жеткілікті. Чат үшін - мәтін мен таңдалған файлдар.

Қалыпты сценарий былай көрінеді: пайдаланушы жолда телефоннан хабарлама жібереді, желі үзіледі, ол батырманы тағы басады. Бірінші сұраныс серверге әлдеқашан жеткен, екіншісі сол бірдей идемпотенттік кілтпен келді. Интерфейс қызыл қате көрсетпейді және екінші хабарлама жасамайды. Ол сабырмен: "Хабарлама жіберілді" деп жазады.

Осылайша формалардың қосарланған жіберілуі мен чаттағы қайталанған хабарламалар жүйе үшін жоғалады да, адамға сезілмей қалады. Пайдаланушы retry, queue және желі ақаулары туралы ойламайды. Ол тек сұраныс жоғалмағанын көреді.

Клиент, сервер және кезек үшін схема

Жұмыс істейтін схема серверден емес, клиенттен басталады. Егер пайдаланушы формада батырманы екі рет басса, желіні жоғалтса немесе қосымша өзі қайта жіберуге шешім қабылдаса, жүйе керісінше дәлелденгенге дейін мұны бір әрекет деп санауы керек.

Осы үшін клиент бірінші сұранысқа дейін бірегей id жасайды. Сол бір id-ді ол әр қайта жібергенде де жібереді, сұраныс мобильді желі арқылы қайта кетсе де, SDK ішіндегі retry болса да, таймауттан кейінгі тағы бір талпыныс болса да.

1. Клиент request_id-ді жіберер алдында жасайды да, оны әрекет draft-ымен бірге сақтайды.
2. Сервер сұранысты қабылдайды, осы id-ді storage-тан іздейді де, мұндай шақыру бұрын болған-болмағанын бірден түсінеді.
3. Егер бұл алғашқы талпыныс болса, сервер әрекетті орындайды, соңғы жауапты сақтайды және сұранысты өңделген деп белгілейді.
4. Егер сол id-мен қайталау келсе, сервер екінші жазба жасамайды, бірінші талпыныстан кейін сақталған сол жауапты қайтарады.
5. Егер сервер тапсырманы кезекке қойса, сол id-ді әрі қарай да береді, ал worker оны өз логтары мен өңдеу нәтижесіне жазады.

Мұндай тәртіп болжамды мінез-құлық береді. Пайдаланушы екі тапсырыстың, екі хабарламаның немесе екі есептен шығарудың орнына бір нәтиже көреді.

Серверде қайталанудың өзін ғана емес, алғашқы өңдеудің нәтижесін де сақтау маңызды. Әйтпесе сіз дубликатты ұстайсыз, бірақ клиентке дәл сол body және дәл сол status-пен адал жауап қайтара алмайсыз. Практикада бұл UX-ті бұзады: интерфейс сұраныс сәтсіз болды деп ойлайды, ал сервер бәрін әлдеқашан орындап қойған.

Кезектерде де логика сол. Егер broker немесе worker қайталау жасаса, жаңа id ойлап табуға болмайды. Әйтпесе бір әрекет бірнеше тәуелсіз оқиғаға бөлініп кетеді де, дедупликация ең қымбат жерде - базаға жазғаннан немесе сыртқы сервисті шақырғаннан кейін - істемей қалады.

Логтар да бүкіл тізбек бойымен бір id-ге байланғаны дұрыс: клиент, API, queue, worker, external call. Егер команда LLM сұраныстарын AI Router арқылы жіберсе, дәл сол id-ді модельді шақырғанға дейін де, audit-логтарға да беру пайдалы. Сонда даулы жағдай тез шешіледі: бірінші сұраныс қайда болды, retry қай жерде шықты, пайдаланушы неліктен қайталауды көрді - бәрі анық көрінеді.

Чаттарда нені өзгерту керек

Чатта әрекеттің бірлігі - батырманы басу емес, хабарламаның өзі. Пайдаланушы мәтінді жіберген сәтте клиент message_id жасап, оны сол хабарламаның өмір бойы сақтауы керек: экран қайта салынса да, қайта қосылса да, кез келген retry болса да. Егер UI компонент жаңарғаннан кейін жаңа id жасап қойса, дубликатты өзіңіз жасадыңыз деген сөз.

Чаттағы қайталанған сұраныстарды дедупликациялау әдетте бір ережеге тіреледі: пайдаланушының бір мағыналы енгізуі = бір id. Бұл id-ді серверге мәтінмен бірге жіберу керек, ал сервер нәтижені соған қарай сақтауы тиіс. Егер желі дір етіп, клиент сұранысты қайталаса, сервер екінші жазба жасамайды, бұрыннан белгілі хабарламаны және оның ағымдағы статусын қайтарады.

Жиі кездесетін жаман сценарий мынадай: таймаут болды, UI жауапты күтпей жаңа хабарлама жасады да, мәтінін бұрынғысымен бірдей қалдырды. Пайдаланушы екі бірдей репликаны көреді, ал модель екеуіне де жауап береді. Одан да жақсысы - тарихта бір ғана көпіршік қалдырып, тек оның күйін өзгерту: "жіберілуде", "жеткізілді" немесе "қате".

Стриминг кезінде не істеу керек

Стримингте тасымалдау ақауын пайдаланушының жаңа енгізуімен шатастырып алу оңай. Егер SSE немесе WebSocket жауаптың ортасында үзілсе, бұл әлі жаңа хабарлама деген сөз емес. Клиентке генерацияны қайта бастауға емес, бұрыннан бар response_id-ге қайта байланысуға немесе жауаптың ағымдағы күйін сұрауға ыңғайлы.

Жаңа жауап тек пайдаланушы жаңа мәтінді жаңа message_id-мен жібергенде ғана керек. Ағынның үзілуі, ACK-тың қайталануы немесе чанктың қайта жеткізілуі тарихта жаңа реплика жасамауы тиіс.

Практикада төрт ереже жеткілікті: message_id-ді клиентте растау немесе ашық қате шыққанша сақтау, retry кезінде сол id-ді жіберу, жауап ағынын нақты хабарламаға байлау және желі бірнеше рет қайта қосылса да, тарихта бір ғана элемент көрсету.

LLM-чатта бұл әсіресе байқалады. Пайдаланушы "Хатты қысқаша түйіндеп бер" деп жіберді, мобильді желі бір сәтке өшіп қалды, қосымша сұранысты қайта жіберді. Егер id өзгермесе, сервер сол бір хабарламаны қайтарады, ал тарих таза қалады. Егер id ауысса, екі бірдей сұрақ, екі есе токен шығыны және диалогтағы шатасу пайда болады.

Формалар мен фондық тапсырмаларда нені өзгерту керек

Формалар мен фондық тапсырмаларда ортақ мәселе бір: пайдаланушы немесе желі сұраныс жоғалды деп ойлап, оны қайта жібереді. Егер сервер бұл талпыныстардың байланысын көрмесе, артық өтінімдер, қайталанған есептен шығару немесе ұзақ жұмыстың екінші рет басталуы пайда болады.

Формалар

Пайдаланушы "Жіберу" батырмасын басқанда, сол талпынысқа тұрақты id бекітіп, оны бет қайта жүктелгенше немесе деректер анық өзгергенше сақтаңыз. Егер браузер қосарланған басу, әлсіз мобильді желі немесе клиент кодындағы автоматты retry салдарынан сұранысты тағы жіберсе, сервер сол id-ді көріп, мұның жаңа әрекет емес екенін түсінеді.

Форма ізтаңбасы да пайдалы, бірақ оны мұқият жинау керек. Оған өздігінен өзгеретін өрістерді қоспаңыз: жіберу уақыты, кездейсоқ nonce, қызметтік санағыш немесе қайта рендерден кейінгі өрістердің реті. Әйтпесе екі бірдей сұраныс әртүрлі болып көрінеді.

Жаңа жіберу тек деректер шынымен өзгергенде ғана пайда болуы керек. Егер адам форманы ашып, батырманы екі рет басып, ештеңені өзгертпесе - бұл сол бір талпыныс. Егер ол телефонды немесе пікірді түзетсе, бұл енді жаңа әрекет, демек id-ді қайта жасау керек.

UI үшін ереже қысқа: бірінші жіберу сәтінде id жасаңыз, дерек өзгермейінше оны сақтаңыз, retry кезінде id-ді өзгертпеңіз және "жіберілуде" немесе "қабылданды" сияқты түсінікті күй көрсетіңіз.

Фондық тапсырмалар

Егер форма тапсырманы кезекке қойса, сол id-ді барлық кезеңде өзгеріссіз өткізіңіз. Бір id API-ге, queue-ге және worker-ге дейін жетуі керек. Әйтпесе форма қорғалғанмен, кезек бәрібір жұмысты екі рет іске қосады.

Ұзақ тапсырмалар үшін күйді сақтаңыз: "қабылданды", "жұмыста", "дайын", "қате". Сонда қайталанған сұраныс процесті қайта бастамайды, тек ағымдағы статусты немесе дайын нәтижені қайтарады. Бұл batch-өңдеу, fine-tuning немесе модель жауаптарын жаппай бағалау сияқты ауыр операциялар үшін әсіресе маңызды.

Дәл осы тәсіл AI Router үшін де пайдалы: егер клиент сұранысты қайталаса, ішкі тапсырма бір жұмысты екінші рет бастамауы және артық ресурс жұмсамауы керек. Бір id, бір күй, бір нәтиже.

Жиі жіберілетін қателер

Ең жиі қате қарапайым: дедупликация тек фронтенде ғана бар. Батырма бұғатталады, спиннер айналады, екінші басу өтпейді, бәрі бақылауда сияқты көрінеді. Бірақ мобильді желі сұранысты қайта жіберуі мүмкін, сервердегі retry өзі іске қосылуы мүмкін, ал кезек бір хабарламаны қайтадан бере алады. Егер сервер сұраныстардың идемпотенттілігін тексермесе, экрандағы қорғаныс көп көмектеспейді.

Тағы бір жиі қате - дедупликация терезесінің дұрыс болмауы. Қысқа терезе тұрақты Wi-Fi-дағы тестте жақсы көрінеді, бірақ шынайы өмірде адам лифтте желіден ажырап, қайта қосылуды күтіп, сол сұранысты 20-40 секундтан кейін байқамай қайта жіберуі мүмкін. Егер алғашқы сұраныс туралы жазба сол кезде өшіп қалса, жүйе дубликатты жаңа әрекет деп қабылдайды.

Тым ұзақ терезе де кедергі. Пайдаланушы әдейі бір хабарламаны чатқа қайта жібергісі немесе біраз уақыттан кейін форманы қайта толтырғысы келуі мүмкін. Егер жүйе әрекетті тым ұзақ уақыт ескі деп санаса, ол адал қайталауларды да басып тастай бастайды.

Мәселе әр retry кезінде жаңа id жасалғанда да шығады. Тестте бәрі дұрыс сияқты, бірақ алғашқы таймаутта бір әрекет бірнеше тәуелсіз сұранысқа бөлініп кетеді. Сервер енді оның қайталану екенін түсіне алмайды.

Тағы бір қате - тек дедупликация фактісін сақтап, алғашқы өңдеудің нәтижесін сақтамау. Ондайда сервер дубликатты таниды, бірақ бұрынғы жауаптың body-і мен status-ының орнына "бұрын болған" сияқты бірдеңе қайтарады. Пайдаланушы қайтадан әрекет өтті ме, жоқ па - түсінбей қалады.

Соңында, id-ді API, кезек және worker арасында жоғалтып алмаңыз. Бұл ойлағаннан жиі болады. Кірісте сізде бір ғана талпыныс бар, ал жүйенің ішінде кенет екі түрлі id-і бар екі оқиға пайда болады. Содан кейін кезектен келген қайталаулар енді біріктірілмейді.

Практикадан қысқа сценарий

Пайдаланушы метрода келе жатып, телефоннан форма жібереді: мысалы, кері қоңырауға өтінім немесе қолдау қызметіне сұрау. Ол батырманы бір рет басады, айналып тұрған индикаторды көреді, бірақ тоннельде байланыс үзіледі. Экран жауапты уақытында алмай, таныс хабарды көрсетеді: қайта көріңіз.

Адам батырманы қайта басады. Оның көзінде бұл - бір ғана әрекет. Жүйе үшін болса, бұл бірнеше секунд айырмасымен келген екі бірдей сұраныс.

Егер қорғаныс нашар жасалса, сервер екі өтінім жасайды. Сосын екеуі де кезекке түседі, оператор көшірмелерді көреді, ал пайдаланушы бірінің орнына екі қоңырау алуы мүмкін. Қағаз жүзінде бұл ұсақ нәрсе сияқты. Іс жүзінде мұндай дубликаттар есепті бұзады, қолдау қызметінің уақытын алады және жай ғана ашуландырады.

Қалыпты сценарий басқаша жұмыс істейді. Қосымша сұранысты бір ғана client_request_id-мен жібереді. Қайта жіберу де сол id-мен кетеді, тіпті пайдаланушы тағы басса да. Сервер бұл id-ді идемпотенттілік қоймасынан тауып, әрекет әлдеқашан қабылданғанын түсінеді. Жаңа жазба жасаудың орнына алдыңғы статусты немесе дайын жауапты қайтарады. Кезекке бір ғана тапсырма түседі, екеу емес.

Пайдаланушы көбіне жүйе қайталауды қалай өңдегенін байқамайды да. Ол жай ғана түсінікті қорытындыны көреді: форма қабылданды, өтінім нөмірі сол күйінде қалды, екінші дубликат шықпады. Мұндай дедупликация адамның мінез-құлқына қарсы тұрмайды. Ол қарапайым фактіден шығады: нашар желіде адамдар батырманы қайта басады.

Қолдау қызметі үшін де айырмашылық бірден көрінеді. CRM-де бір ғана өтінім бар, бірдей карточкалар үйіндісі емес. Оператор қай көшірмені жабу керек екенін салыстырып уақыт жоғалтпайды. Кезек артық жұмысты айналдырмайды, ал фондық өңдегіштер қайталанған хабарламаларды жібермейді.

Өндірісте дедупликация дәл осылай жұмыс істеуі керек: тыныш, болжамды және нашар байланыс үшін пайдаланушыны жазаламай.

Іске қосар алдындағы жылдам тексеріс

Релиз алдында бірдей сұраныс id-імен қысқа тест жасаңыз. Сұранысты үш рет жіберіңіз: бірден, 2-3 секундтан кейін және жасанды таймауттан соң. Бірінші шақыру жаңа әрекет ретінде өтуі керек, ал келесі екеуін жүйе қайталау деп тануы тиіс.

Чат үшін бұл тез тексеріледі. Тарихта пайдаланушының бір ғана хабарламасы және бір ғана жауабы қалуы керек, тіпті жіберу батырмасы бірнеше рет басылса да немесе мобильді желі байланысқа әсер етсе де. Егер чат дубликат салса, демек клиент немесе сервер id-ді тым кеш салыстырып отыр.

Форма үшін тексеріс қатаңырақ. Бірдей сұраныс базаға бір ғана жазба және кезекке тек бір job жасауы керек. Команда көбіне тек базаны қарап, бәрі дұрыс деп тынышталады да, кейін кезекке екі бірдей тапсырма түскенін байқайды. Нәтижесінде хат екі рет кетеді, құжат екі рет жасалады немесе лимит қайтадан есептен шығарылады.

Төрт нәрсені тексеріңіз:

• сервер бірдей id-мен қайталанған жіберуге сол нәтижені қайтарады
• чат бір хабарламаны көрсетеді, бір мәтіннің көшірмелерін емес
• форма бір жазба жасайды және кезекке бір job қояды
• логтарда жеке деректер ашылмай, сұраныс id-і сақталады

Логтарды бөлек ашып, әр сұраныс бойынша шешім көрініп тұрғанын тексеріңіз: жаңа ма, әлде қайталану ма. Егер сіз PII-ді маскалап отырсаңыз, логтарда телефон, email, ИИН, мекенжай және адамды анықтауға болатын басқа да өрістер қалмауына көз жеткізіңіз.

Id сақтау мерзімін де тексеріңіз. Егер жүйе id-ді тым ерте ұмытса, кезектен немесе тұрақсыз желіден келген қайталаулар жаңа сұраныс болып өтіп кетеді. Егер id-ді тым ұзақ сақтасаңыз, пайдаланушы уақыт өткен соң бұрын дұрыс болған әрекетті қайта жасай алмай қалады. Чат үшін көбіне қысқа терезе жеткілікті. Ал фондық тапсырма үшін терезе ұзағырақ керек.

Егер бұл тест интерфейсте дубликатсыз, базада екінші жазбасыз және артық job-сыз өтсе, схема қазірдің өзінде сау көрінеді. Әсіресе қате ақшаға әсер ететін немесе пайдаланушымен әңгімеге нұқсан келтіретін жерде бұл - жақсы минимумы.

Әрі қарай не істеу керек

Бүкіл схема тез шашырап кетпес үшін бір негізгі шешімнен бастаңыз: әрекет id-і қай жерде пайда болатынын анықтаңыз. Форма үшін бұл әдетте алғашқы жіберуге дейінгі клиент. Чатта да әр хабарламаға id-ді клиентте жасау жақсырақ, тіпті желі үзіліп, қосымша оны қайта жібермек болса да. Фондық тапсырмада id-ді көбіне сервер кезекке қойған кезде жасайды, бірақ содан кейін оны енді өзгертуге болмайды.

Егер бұл ереже болмаса, дедупликация кездейсоқ тексерулер жиынтығына айналады. Бүгін сіз қосарланған басуды ұстайсыз, ертең мобильді желіден келген retry-ді, ал арғы күні жаңа техникалық идентификаторы бар кезек қайталауын аласыз да, оны алғашқы сұраныспен байланыстыра алмайсыз.

Содан кейін қарапайым ережелер кестесін бекітіңіз. Ол бір ғана әзірлеушінің басында емес, тапсырмада, ADR-де немесе қысқа ішкі жаднамада болуы керек. Әр сценарий үшін id-ді кім жасайтынын, оның қанша өмір сүретінін, қайталау деп нені санайтыныңызды және дубликат келгенде жүйе қандай жауап қайтаратынын жазыңыз. Id API, queue, worker және логтар арқылы қалай өтетінін де бөлек белгілеңіз.

Тағы бір пайдалы ереже: тек id-ді емес, алғашқы өңдеудің нәтижесін де сақтаңыз. Әйтпесе сіз қайталауды танып, бірақ сабырлы және бірізді жауап қайтара алмайсыз.

Осы қадамдарды ғана жасасаңыз да, дубликаттардың көп бөлігі бастапқыда-ақ кетеді. Ал қайталау бәрібір кездессе, жүйе оны апат ретінде емес, қалыпты жағдай ретінде өңдейді.