අපගේ පද්ධතියේ webhook පණිවිඩයක් 6 පැය පුරා කුමන අවධාරණයක් නොමැතිව අතුරුදන් වූ අවස්ථාවක්, බොහෝ සමාගම්ට සමාන පරිදි, ගනුදෙනුකරුවෙකුගේ ඊමේල් පණිවුඩයකින් හඳුනාගන්න ලැබුණා. ඒ සිදුවීම අපේ සේවාදායකයාට ගෙවීම් තත්ත්වය යාවත්කාලීන කිරීමට බලාපොරොත්තු වූ පණිවිඩයක් නොපැමිණීම ලෙස පෙනුනා.
ලොග් පරීක්ෂා කිරීමෙන් පසු, අපිට තේරුණේ TLS සහතිකයක් නවීකරණය කිරීමේදී සේවාදායකයාගේ හස්තලේඛනය (handshake) අපගේ client library එකට අනුකූල නොවීමයි. එම අවස්ථාවේ webhook sender එක එය “delivery failure” ලෙස ලොග් කරමින්, කිසිදු retry mechanism එකක් නොමැතිව ඉදිරියට යන ලදී. දෙවසරක සාර්ථකත්වය නිසා retry අවශ්යතාවය අමතක වූ අතර, ඒ නිසා “always” කියන වචනයේ අඩුපාඩු පෙන්වා දුන්නා.
Retry සහ Backoff සැලැස්වීම
පළමු අදහස වුණේ 30 තත්පරයකට වරක්, 5 මිනිත්තු පරතරයකින් retry කිරීමයි. නමුත් ඒක downstream සේවාවට “thundering herd” ප්රතිඵලයක් දෙනවා. ඒ නිසා අපි exponential backoff ක්රමයට මාරු වුණා – 10 තත්පරයෙන් ආරම්භ කර, දෙගුණයක් කරමින් 30 මිනිත්තු තෙක්, සෑම උත්සාහයකම ±20% jitter එකක් එක් කරමින්. මෙය සම්පුර්ණයෙන්ම වාරික 6 වාරයක්, සම්පූර්ණයෙන්ම 2 පැය පමණ පළවෙනි retry පසු, පණිවිඩය dead‑letter queue (DLQ) එකකට යවයි.
Dead‑Letter Queue (DLQ) – සැබෑ විසඳුම
DLQ එකේ සරල වගුවක් – event ID, destination, payload, attempt history, last error – තිබේ. මෙය “vanish” වීමේ තැනට පළාතක් ලෙස කටයුතු කරයි. ඒ සමඟම replay tool එකක් එකවරම සකසා, DLQ හි පණිවිඩය පරීක්ෂා කර නැවත යැවීමට හැකියාව ලැබේ. එක් පැයකට 20 කට වැඩි DLQ පණිවිඩයක් එකතු වුවහොත් on‑call engineer කෙනෙකුට page එකක් එවීමට සැකසූවා. මෙය partner endpoint එක අඩුපාඩු ගැලපෙන්නේ දැයි වහාම හඳුනා ගැනීමට උපකාරී.
Idempotency සහ අනුකූලතාව
Retry කිරීමේදී පණිවිඩය නැවත යැවීමේදී duplicate ක්රියාකාරකම් නොසිදු වන ලෙස, සියලු webhook payload සහ header වල UUID එකක් එක් කරා. ඒ පිළිබඳව integration guide එකේ “dedupe” කිරීම අනිවාර්ය බව පැහැදිලි කළා. මෙය contract change එකක් වන නිසා, පවතින partners ලට පෙර දැනුම් දී, ඔවුන්ගේ system එකට සකස් කර ගැනීමට කාලය දුන්නා.
අසාර්ථකතා වර්ගීකරණය
500 (server error) response එකක් retry කළ යුතුයි, නමුත් 400 (client error) response එකක් payload වැරදි නිසා retry කිරීම අර්ථවත් නොවේ. ඒ නිසා අපි send time එකේ error code අනුව backoff ක්රමය පමණක් යොදා ගන්නවා.
ශ්රී ලංකාවට ඇති වැදගත්කම
මෙම පළපුරුද්ද ශ්රී ලංකාවේ developers, startups, සහ IT service providers සඳහා විශාල පාඩමක්. සිදුවූ ගැටලුවක් නිසා:
- API reliability ගැන අවධානය වැඩි වුණා.
- Retry, backoff, DLQ වැනි best‑practice patterns ඉගෙන ගන්න ලැබුණා.
- දත්ත අහිමි වීම වැළැක්වීමට idempotency keys භාවිතය අත්යවශ්ය බව තේරුණා.
- ඔන්‑කෝල් alerting සහ monitoring සකස් කිරීමේ වැදගත්කම දැනගත්තා.
ඉදිරියට, ශ්රී ලංකාවේ තාක්ෂණික සමාජය මෙම පළපුරුද්දෙන් පදනම්ව තමන්ගේ integration architecture ගොඩනැගීමට, ගනුදෙනුකරුවන්ට විශ්වාසනීය සේවාවන් ලබා දීමට හැකියාව ලැබේ.
අවසන් වශයෙන්, “fire‑and‑forget” පදනමක් මත පදනම් වූ system එකක්, real‑world load එකේදී අධික risk එකක් ගෙන ඒන බව පෙන්වා දුන්නා. දැන් retry, DLQ, සහ idempotency යන අංගයන් සමඟ, අපගේ webhook සේවාව 24/7 විශ්වාසදායකව ක්රියා කරන බවට විශ්වාසයි.
