Dev.to වෙතින් පළ වූ නව ලිපියක්, Outbox pattern එකේ “lease expiry” සිදුවීමෙන් පසු duplicate message එකක් බ්රෝකර් වෙත යැවෙන්නේ කෙසේද, එය කොහොමද පාලනය කරන්නෙ කියලා පැහැදිලි කරයි.
කල්පනා කරමු, Relay A එක outbox පේළිය 42 එකට lease එකක් ගන්නා අතර එය පණිවිඩය ප්රකාශ කරයි. A, පණිවිඩය publish කරයි කියලා ලේඛනගත කිරීමකට පෙර, එහි lease කාලය ඉවර වේ. එවිට Relay B එක ඒම පේළිය claim කරලා, නැවත පණිවිඩය යවයි. දෙදෙනාම තමන්ගේ දත්ත තත්ත්වය අනුව ක්රියා කළාත්, බ්රෝකර් එකට duplicate message එකක් ලැබෙයි.
මෙම ගැටලුවට විසඳුමක් ලෙස “fencing token” යොදාගෙන lease එකක් අලුත් කරන සැම විට token එක වැඩි කරනවා. මෙය stale (කාලය ඉක්මුණු) relay එකට අලුත් lease එකේ completion සලස්වීමට ඉඩ නොදෙයි. Token එක, පරණ relay එකේ publish කිරීම නව lease එකේ publish කිරීම මත බලපාන්නේ නැතිව තබයි. ඒත් duplicate message එක අඩු නොවේ; එය consumer (පාරිභෝගික) පාර්ශවයේ idempotent logic එකෙන් හසුරවන්න ඕන.
ඉතින්, පණිවිඩය එකවරම business effect (උදා: ගිණුමට $10 credit එක) සිදු වීමට, consumer එක event_id හා consumer නාමය සමඟ transaction එකක insert කරලා, conflict එකක් ඇතිවුවොත් කිසිදු වැඩක් නොකරන පරිදි සැකසිය යුතුය. මෙයින් “handler ran once” කියන නියමය නොව, “එක consumer‑event සම්බන්ධයෙන් credit එක වැඩි වීම වැඩිම තරමේ එක් වතාවක් පමණක් commit වීම” යන invariant එකක් පවත්වා ගත හැක.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ තාක්ෂණික සමාජය, විශාල data pipelines, event‑driven architecture හෝ micro‑services පද්ධති නිර්මාණය කරන විට මේ නව ක්රමය ඉතා ප්රයෝජනවත්. විශේෂයෙන්:
- සංවර්ධකයන් – lease token හා fencing token යොදා ගනිමින්, system crash හෝ network latency නිසා duplicate messages ඉවත් කර, code එකේ සංකීර්ණ retry logic එකක් ලියන අවශ්යතාව අඩු වේ.
- ව්යාපාරිකයන් – credit, inventory update වැනි financial transaction වල duplicate processing වැලැක්වීමෙන්, ආර්ථික අලාභය හා පාරිභෝගික විශ්වාසය රැකගත හැක.
- අධ්යාපනිකයන් – event sourcing, outbox pattern, idempotent consumer design වැනි concepts ඉගෙන ගැනීමට, practical example එකක් ලෙස මෙම ලිපිය උදව් වේ.
අවසානයේ, lease expiry පාලනය, fencing token, සහ idempotent consumer design එකක් එක්ක, ශ්රී ලංකාවේ developers ලට scalable, reliable, හා fault‑tolerant පද්ධති ඉදිරිපත් කිරීමේ හැකියාව වැඩි වේ.
ඉදිරියේදී, outbox pattern එකේ transaction‑level coordination නොමැතිව, exact‑once delivery නියම කිරීම අභියෝගයකි. ඒ වෙනුවට, duplicate messages අඩු කර, business logic එක idempotent ලෙස සැලසුම් කිරීමේ වැදගත්කම තේරුම්ගත යුතුයි.
