අද කාලයේ ඕනෑම වෙබ් යෙදුමක් හෝ මොබයිල් ඇප් එකක් පාරිභෝගිකයින්ට තොරතුරු දැනුම් දීමට නිවේදන මාර්ගයක් අවශ්ය කරයි. පළමු අවස්ථාවේ එය සරලයි – නව ලියාපදිංචියක්? ඊමේල් එකක්; ලිපියකට ලයික් එකක්? පুশ් නෝටිෆිකේෂන්; ඇණවුමක් යැවූවාද? SMS එකක්. එහෙත් පද්ධතිය විශාල වීමත් සමඟ මෙම “සරල” ක්රියාමාර්ගය බරපතල ගැටළු වලට හේතුවේ.
කොහේදෝ පණිවිඩ දෙවරක් යැවෙයි, කොහේදෝ පූර්ණයෙන්ම අතුරුදහන් වේ. බාහිර සපයන්නන් අස්ථිච්ඡේදයෙන් වැරදී, පරිශීලකයින් වැදගත් අනතුරු ඇඟවීම් ලැබුනේ නැති බව පැමිණිලි කරති. එම නිසා “නොවැදගත්” යැයි සිතූ ලක්ෂණයක් දැන් ව්යාපාරයේ විශාල අවදානමක් බවට පත්වේ.
නියම නියමය 1: නිවේදන සෘජුවම නොකල යුතුය – ව්යාපාරික තර්කය හා නිවේදන තර්කය එකට ගැළපීම වැරදියි. උදාහරණයක් ලෙස, OrderService එක ඇණවුම සුරකින්න, කාඩ්පත ගාස්තු ගෙවන්න, ඊමේල් යවන්න යන ක්රියාවලියන් එකට රැස් කිරීම. ඊමේල් සපයන්නා අස්ථිච්ඡේදයෙන් වැරදුනොත්, ඇණවුම අසාර්ථක විය යුතුද? නැත. නිවේදන ක්රියාකාරකම් වෙන් කර, සිදුවූ අවස්ථාවක් (Event) පළ කිරීමෙන් පසු Notification Service එකට යොමු කිරීම වඩා හොඳය.
සිදුවීම් මත පදනම් වූ සැලසුම – “ඊමේල් යවන්න” කියා නොකියලා “OrderCreated” සිදුවීමක් ලෙස සලකන්න. එම සිදුවීමට අනුව ඊමේල්, SMS, පুশ්, ගබඩා දැනුම්දීම, විශ්ලේෂණ යනාදිය ස්වයංක්රීයව ක්රියාත්මක වේ. කවුද අසාදනවාද යන්න කෙනෙක් දැනගැනීමට අවශ්ය නැත; පද්ධතියේ විස්තාරය සරළයි.
කියු (Queue) භාවිතය – බාහිර API එකක් දෙකක්, දෙකක්, වසරක් ගත විය හැකිය. ඒවා API ඉල්ලීම් සමඟ සම්බන්ධ කරන්නේ නම්, පරිශීලකයාගේ ප්රතිචාර වේගය අඩුවේ. ඒ වෙනුවට ඇතුළත් දත්ත සුරකින අතර, නිවේදන කාර්යය කියු එකකට දමන්න. පසුපස වර්කර් එක ඒ කියු එකෙන් පණිවිඩයන් ගනිමින්, ස්වයංක්රීය නැවත උත්සාහ, මාර්ග වෙන් කිරීම, මොනිටරින් වැනි වාසි ලබා දෙයි.
නිවේදන ජීවිත චක්රය – “Pending”, “Queued”, “Processing”, “Sent”, “Delivered”, “Failed”, “Retrying”, “Expired” වැනි තත්ත්වයන් නිරීක්ෂණය කිරීම මඟින් පණිවිඩය කවුරුන්ගෙන් අසාර්ථක වුණාද, කීයද යන තොරතුරු ලැබේ. මෙය දෝෂ නිරාකරණය සරල කරයි.
බහු-චැනල් සැලසුම – පරිශීලකයන්ගේ ඉල්ලීම් අනුව Email, Push, SMS, Slack, WhatsApp වැනි මාර්ග එක්කොට ගත හැක. ඒ සඳහා “NotificationChannel” අතුරුමුහුණතක් නිර්මාණය කර, ප්රතිලාභය එකම ආකාරයෙන් ඉදිරිපත් කරයි. නව මාර්ගයක් එක්කීමට කේතය වෙනස් කිරීමේ අවශ්යතාවයක් නැත.
පරිශීලක පසුබැසීම – නිවේදන ඉතා අධික වුවහොත් පරිශීලකයා අකාරාදාරයක් ගනී. ඒ නිසා Marketing Emails, Order Updates, Security Alerts වැනි ප්රභේද වෙන් කර, පරිශීලකයාට තම කැමැත්ත අනුව සකස් කළ හැකිය.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ තරුණ ඩිවෙලපර්ලා, ස්ටාර්ට්අප් සමාගම් සහ විශාල ව්යාපාරිකයන්ට මෙම සැලසුම ඉතා ප්රයෝජනවත්. පළමුව, Event‑Driven Architecture එකෙන් මොබයිල් යෙදුම් සහ වෙබ් සේවා අතර සම්බන්ධතා තද කර ගත හැක. දෙවැනි, කියු (Queue) භාවිතයෙන් API වේගය වැඩි කර, පාරිභෝගික අත්දැකීම වඩා හොඳ වේ. තෙවැනි, ජීවිත චක්ර නිරීක්ෂණය මඟින් දෝෂ හඳුනා ගැනීම ඉක්මනින් සිදු වේ, එමෙන්ම බහු-චැනල් පද්ධතියෙන් පරිශීලක අවශ්යතා වෙනස් වීමේදී ඉක්මනින් අනුකූල කළ හැක. මේ සියල්ලම තාක්ෂණික ව්යාපාරවල විශ්වාසය, ආදායම, සහ පාරිභෝගික රැකවරණය වැඩි කරයි.
නිවේදන පද්ධතියේ සැලසුම සරල නොවූවත්, ඉහත පියවර අනුගමනය කළහොත්, ඔබේ යෙදුම දිගු කාලයක් පවත්වා ගත හැකි, දෝෂ රහිත, සහ පරිශීලක‑මිතුරක පද්ධතියක් බවට පත්වේ.
