ඔබගේ SaaS යෙදුමට පාරිභෝගිකයින් ගණනාවක් එක්කීමට සූදානම් වන්නේ නම්, ‘කවුද කුමන සංවිධානයේ?’ කියන ප්රශ්නයට පිළිතුරු දෙන පද්ධතියක් අවශ්යයි. පසුගිය ලිපියෙන් සංවිධානය‑පදනම් වූ පරිශීලක කළමනාකරණය ගැන කතා කළා, ඒත් දැන් අපි එම පදනම දත්ත ගබඩා මට්ටමේත් නිවැරදිව ක්රියාත්මක කරන ආකාරය ගැන කතා කරමු.
Multi‑tenancy කියන්නේ එකම යෙදුමක් තුළ බොහෝ පාරිභෝගිකයන් (tenants) එකට සේවය කරන විදිහ. එහි අත්යවශ්ය තීරණයක් තමයි ‘කොහේ tenant‑වෙදිකාව තබාගන්නෙ?’ කියලා. ඒ සඳහා මූලිකවම ත්රිත්වයක් පවතියි: shared‑schema, schema‑per‑tenant, සහ database‑per‑tenant.
Shared‑schema මොඩලේ සියලු tenant‑වරුන්ගේ දත්ත එකම වගුවේ, organization_id කෝෂය මගින් වෙන් කරයි. මෙය වැඩිදියුණු කිරීමේ පියවර අඩුයි – එකම සකස් කිරීම, එකම connection pool, එකම index. නමුත් දෝෂයක් – WHERE organization_id = ? කොන්දේසිය අමතක වීම – සිදු වුනොත්, දත්ත හරහා ලික්කයක් සිදු වේ. එය ඉක්මනින් හඳුනාගත නොහැකි විය හැක.
Schema‑per‑tenant ආකෘතියේ එක් එක් සංවිධානයට තමන්ගේ PostgreSQL schema එකක් ලබා දේ. මෙහිදී tenant‑වෙදිකාව අමතක වුවත්, වෙනත් schema එකේ දත්ත පෙනෙන්නේ නැත; query එක වැරදි නම් error හෝ හිස් ප්රතිඵල ලැබේ. නමුත් මෙය පරිපාලන පාර්ශවයෙන් බරපතළයි – migration එකක් සෑම schema එකකටම කරන්න වෙනවා, connection routing එකත් tenant අනුව සකස් කළ යුතුයි.
Database‑per‑tenant මොඩලේ සෑම සංවිධානයක්ම වෙනම දත්ත ගබඩාවක් (database) ලැබේ. මෙය ආරක්ෂාවෙන් පිරිපුන්ව, compliance, data‑residency වැනි ඉල්ලීම් ඇති ව්යාපාරික ගනුදෙනුකරුවන්ට සුදුසුය. එහෙත් මෙය වැඩිම පරිපාලන පිරිවැය සහිතව, connection pool එක tenant ගණනෙන් ගුණාකාරයෙන් වැඩි වෙයි, migration එක fleet‑wide rollout එකක් වීමෙන් කට්ටලයක් කරගත යුතුය.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ තරුණ සංවර්ධකයින්, startup‑වලට සහ IT සේවා සපයන්නන්ට මෙම තේමාව වැදගත් කාරණා කිහිපයක් ඇත:
- ඉහළ ආරක්ෂාව අවශ්ය ගනුදෙනුකරුවන් සමඟ වැඩ කිරීමට schema‑per‑tenant හෝ database‑per‑tenant මොඩලය තේරීමට හැකියාව.
- අඩු පරිපාලන පිරිවැය සහ වේගවත් සංවර්ධනය සඳහා shared‑schema ආකෘතියෙන් ආරම්භ කළ හැකිය.
- PostgreSQL රෝ‑ලෙවල් සිකුරිටි (RLS) භාවිතයෙන් දත්ත වෙන්කිරීමේ තවත් ආරක්ෂක පළලක් ලබා දේ – මෙය කේතකරුන්ට tenant‑id අමතක වීමේ අවදානම අඩු කරයි.
- ඉදිරි කාලයේ compliance audit, data residency අවශ්යතා ඇති ව්යාපාර සඳහා පරිසරය ඉක්මනින් පරිවර්තනය කළ හැකිය.
ඒ නිසා, ශ්රී ලංකාවේ SaaS ආරම්භකයන්ට පළමුව shared‑schema මොඩලයෙන් ආරම්භ කර, පාරිභෝගික අවශ්යතා අනුව schema හෝ database වෙත මාරු වීම “escape hatch” ලෙස සලකන්න.
අවසානයේ, දත්ත ආරක්ෂාව සහ පරිපාලන පිරිවැය අතර සමතුලිතතාවය සොයාගැනීමේ තීරණය, ඔබේ SaaS ව්යාපාරයේ දිගුකාලීන සාර්ථකත්වයට මූලිකය.