Insidente ng API sa Loob ng Isang Linggo: Ang Kawalan ng Idempotency ay Pag-freeze, Hindi Retry Storm

Kapag nagkaroon ng aberya sa network, madalas magpadala muli ng parehong kahilingan ang mga automated client. Kung walang idempotency, ang mga paulit-ulit na API request na ito ay maaaring magdulot ng dobleng bawas sa prepaid balance ng customer. Alamin kung paano gamitin ang transaction locks upang maprotektahan ang pondo ng iyong mga kliyente.

Ang alisto sa hatinggabi at ang katahimikan sa linya

Ipinapakita ng iyong dashboard ang flatline sa paghahatid ng DLR habang tumataas ang trapiko ng papasok na SMS. Ang isang downstream network partition ay nag-drop ng mga TCP packet sa kalagitnaan ng kahilingan, at ang microservice ng iyong kliyente ay nag-assume ng kabiguan. Kung walang wastong mga pananggalang, ang mga awtomatikong kliyente ay magsisimulang mag-hammer sa iyong gateway ng magkakaparehong payload. Nakatingin ka sa isang klasikong retry storm laban sa isang prepaid ledger kung saan ang bawat dobleng kahilingan ay nanganganib na madoble ang debit sa mga balanse.

Bakit ang mga retry na walang guardrails ay nagpapatuyo ng prepaid balances

Kapag naganap ang timeout ng kliyente, ang naive application logic ay agad na nagpapadala muli ng HTTP request. Kung pinoproseso ng iyong routing layer ang mga duplicate na ito nang hiwalay, ang bawat pagtama ng API ay nag-trigger ng sariwang JIT number allocation o sariwang SMS dispatch. Nilalabag nito ang lohika ng USD 20 prepaid floor sa pamamagitan ng pagbaba ng mga balanse sa ibaba ng zero bago ito mahuli ng risk engine. Huwag umasa sa pag-asa o mga pangako ng kliyente.

Pag-isolate sa kabiguan at paghinto sa loop

Ang iyong kagyat na priyoridad sa pagpapatakbo ay ang paghinto sa papasok na trapiko bago mag-patch ng code. Magpatupad ng emergency rate-limiting rule sa API gateway edge upang i-drop ang magkakaparehong payload na dumarating sa loob ng makitid na time window. Huwag subukang magproseso ng mga transaksyon habang ang estado ng ledger ay pinagtatalunan. Kung ang iyong platform ay lumapit sa malambot na pagsusuri malapit sa USD 1,000/buwan na threshold sa disputed traffic volume, ang mga upstream carrier ay maglalagay ng bandila sa iyong merchant ID.

Pag-verify sa estado ng transaksyon at pagkakapare-pareho ng ledger

Sa sandaling humupa ang bagyo, dapat mong i-audit ang bawat pagsasaayos ng balanse na ginawa sa window ng insidente. Ihambing ang iyong mga panloob na log ng ledger laban sa mga signal ng HB ng carrier upang matukoy ang mga orphan request kung saan ang SMS ay naipadala ngunit ang paghahatid ng DLR ay nabigong ma-log. Ang mga developer ay madalas na nagkakamali sa Ikalawang Buwan ng API: Pamamahala sa Idempotency Debt Matapos ang Unang Siklo sa pag-aakalang sapat na ang single-threaded database constraints.

Pag-secure ng paghahatid ng webhook laban sa mga echo replay

Ang paghawak sa mga inbound webhook nang ligtas ay kasing-kritikal ng pamamahala sa mga outbound API call sa panahon ng insidente. Ang mga kliyenteng nagpoproseso ng asynchronous DLR updates ay maaari ring mahulog sa infinite loops kung hindi mo susuriin ang lagda ng webhook at replay window upang i-filter ang mga duplicate. Ang mahigpit na pag-validate ng signature ay pipigil sa mga system ng kliyente na iproseso ang parehong event nang paulit-ulit na nagdudulot ng korupsyon sa ledger.

Magsimula sa IOSOR para sa matatag na kontrol ng transaksyon

Sa linggo ng insidente, i-freeze muna ang bagong outbound. Magdagdag ng Idempotency-Key sa bawat send na nasa hangin, i-export ang dobleng debit row, at itigil ang tahimik na retry ng client. Huwag magbukas ng bagyo ng retry para makaabot.

Buod ng IOSOR

Gawin: ituring ang nawawalang key bilang freeze, tapos punan at i-reconcile ang ledger.

Huwag: isara ang insidente habang ang dobleng DLR ay gumagawa pa ng pangalawang debit. Ang status ng ticket ay hindi status ng pera.