मुख्य सामग्री पर जाएं

सुरक्षा

Webhook की विश्वसनीयता आपके endpoint के व्यवहार पर उतनी ही निर्भर करती है जितनी Unico की delivery गारंटी पर। यह पृष्ठ तीन अपरिवर्तनीय सिद्धांतों को कवर करता है जिनका आपके endpoint को पालन करना होगा: idempotency, concurrency limit, और error rate।

Idempotency​

Unico का webhook implementation at-least-once delivery की गारंटी देता है — एक ही processId के लिए एक ही status एक से अधिक बार notify किया जा सकता है। आपका endpoint अवश्य idempotent होना चाहिए।

अनुशंसित pattern:

  1. प्रत्येक webhook call पर, पहले जाँचें कि processId पहले से process किया जा चुका है या नहीं।
  2. यदि हाँ, तो 2xx तुरंत return करें (काम पहले ही हो चुका है)।
  3. यदि नहीं, तो अपना business logic लागू करें और यह तथ्य persist करें कि यह processId process किया गया था।
// pseudo-code
async function handleWebhook(req, res) {
  const { processId } = req.body;

  if (await alreadyProcessed(processId)) {
    return res.status(200).end();
  }

  await applyBusinessLogic(req.body);
  await markAsProcessed(processId);
  return res.status(200).end();
}
यह क्यों महत्वपूर्ण है

एक non-idempotent endpoint जो प्रत्येक delivery पर business logic चलाता है (जैसे, कार्ड charge करना, email भेजना) retry होने पर कई बार fire होगा — और retries webhook delivery में सामान्य हैं, असाधारण नहीं।

Concurrency limit​

उच्च-मात्रा अवधि के दौरान spikes से आपके endpoint की सुरक्षा के लिए, webhook पंजीकृत करते समय अधिकतम simultaneous in-flight deliveries की संख्या (अधिकतम: 500) configure करें।

जब concurrency limit पहुँच जाती है, Unico अतिरिक्त deliveries को queue करता है और capacity उपलब्ध होने पर उन्हें process करता है। Retries के साथ मिलकर, इसका अर्थ है कि sustained spike नए webhooks के प्रभावी delivery time को बढ़ा सकता है।

Error rate​

Error rate (responses जो 200–299 range से बाहर हैं) हमेशा कम होनी चाहिए। यदि आपका endpoint बड़े पैमाने पर errors return करने लगता है, तो Unico उस endpoint के लिए webhook throughput स्वचालित रूप से कम कर देता है। Retry mechanism के साथ मिलकर, यह नए webhooks के execution time को काफी बढ़ा सकता है।

परिचालन मार्गदर्शन:

  • अपनी तरफ से non-2xx responses monitor करें। अपने सामान्य baseline से ऊपर sustained error rates पर alert करें।
  • अपने webhook handler को critical path के रूप में मानें — यह आपके stack की सबसे विश्वसनीय services में से एक होनी चाहिए।
  • नियोजित maintenance के लिए, load balancer पर intake रोकना बेहतर है बजाय 503 return करने के। लगातार non-2xx responses — 503 सहित — ऊपर वर्णित स्वचालित throughput throttling को सक्रिय करते हैं; जब आपका endpoint पुनः ठीक हो जाता है, तो कम throughput आउटेज के दौरान queue हुए events की delivery में देरी करता है। बिना process किए events के लिए 200 return न करें।

Status semantics​

state और lastEvent values के set को evolvable configuration के रूप में मानें:

  • केवल उन states / events पर react करें जिन्हें आप explicitly handle करते हैं।
  • अज्ञात values log करें — उन पर error न करें।
  • Major version change के बिना नए states जोड़े जा सकते हैं।
अंतिम अपडेट को