SaaS ڈیٹا بیس آرکیٹیکچر ڈیزائن کرنا

پہلے ہفتے میں ڈیٹا بیس کے غلط فیصلے آپ کو برسوں تک پریشان کریں گے۔

ایک SaaS بانی کو ایسے اسکیما (schema) کی ضرورت ہوتی ہے جو multi-tenancy، بلنگ اور ترقی کو سنبھال سکے۔ اگر آپ سے غلطی ہو گئی، تو آپ کو چھ ماہ میں اپنا پورا سسٹم دوبارہ لکھنا پڑے گا۔

یہاں ایک پروڈکشن کے قابل اسکیما بنانے کا طریقہ دیا گیا ہے۔

1. اپنی ٹیننٹ (Tenant) حکمت عملی کا انتخاب کریں

آپ کو صارفین کے درمیان ڈیٹا کو الگ کرنا چاہیے۔

• Row-level (Shared DB): کم پیچیدگی۔ زیادہ تر اسٹارٹ اپس کے لیے بہترین۔ ہر کوئری پر WHERE organization_id = ? فلٹر استعمال کریں۔ • Schema-level (Separate Schemas): درمیانی پیچیدگی۔ ریگولیٹری ضروریات کے لیے موزوں۔ • Database-level (Separate DBs): زیادہ پیچیدگی۔ انٹرپرائز کلائنٹس کے لیے بہترین۔

90% نئے پروڈکٹس کے لیے، row-level multi-tenancy ہی درست انتخاب ہے۔

2. درست اینٹیٹی ہائیرارکی (Entity Hierarchy)

صارفین کو براہ راست بل نہ کریں۔ صارفین آتے جاتے رہتے ہیں۔ تنظیمیں (Organizations) برقرار رہتی ہیں۔

ہائیرارکی کچھ اس طرح ہونی چاہیے: User ── MemberOf ── Organization ── Subscription ── Invoice

• Users: اس ٹیبل کو صرف شناخت کے لیے رکھیں۔ حملوں سے بچنے کے لیے UUIDs استعمال کریں۔ • Organizations: یہ آپ کی ٹیننٹ کی حد (boundary) ہے۔ سبسکرپشنز کو ہمیشہ تنظیم (organization) سے جوڑیں۔ • Memberships: صارفین کو تنظیموں سے جوڑنے کے لیے ایک join table استعمال کریں۔ کردار (roles) یہاں محفوظ کریں، صارف کے ٹیبل پر نہیں۔

3. بلنگ اور سبسکرپشنز

کبھی بھی is_active جیسا سادہ boolean استعمال نہ کریں۔ اس سے ڈیٹا میں الجھن پیدا ہوتی ہے۔

سبسکرپشنز کے لیے state machine استعمال کریں۔ عام حالتیں (states) درج ذیل ہیں: • trialing • active • past_due • canceled • expired • incomplete

یہ آپ کو دستی ڈیٹا کی اصلاح کے بغیر ادائیگی کی ناکامیوں اور گریس پیریڈز (grace periods) کو سنبھالنے کی اجازت دیتا ہے۔

4. رقم اور انوائسنگ

مالیاتی غلطیوں سے بچنے کے لیے ان سخت اصولوں پر عمل کریں:

• رقم کے لیے کبھی بھی FLOAT یا REAL استعمال نہ کریں۔ سینٹس (cents) کو محفوظ کرنے کے لیے integers استعمال کریں۔ مثال کے طور پر، $29.99 بن جائے گا 2999۔ • ایک invoice_line_items ٹیبل استعمال کریں۔ ٹیکس رپورٹس اور ریفنڈز کے لیے آپ کو اس کی ضرورت ہوگی۔ • اگر آپ اس بنیاد پر چارج کرتے ہیں کہ صارف آپ کی پروڈکٹ کتنا استعمال کرتا ہے، تو usage_events ٹیبل استعمال کریں۔

5. کارکردگی کے لیے تجاویز (Performance Tips)

• اپنی foreign keys کو انڈیکس (index) کریں۔ • اپنے status کالمز کو انڈیکس کریں۔ • اپنے timestamp کالمز کو انڈیکس کریں۔ • N+1 کوئریز سے بچیں۔ تنظیم اور سبسکرپشن کا ڈیٹا ایک ہی بار میں حاصل کرنے کے لیے JOINs استعمال کریں۔

ایک اچھا اسکیما کام کرتے وقت نظر نہیں آتا۔ جب یہ ناکام ہوتا ہے تو تباہ کن ثابت ہوتا ہے۔

تنظیم (organization) کے لیے بنائیں۔ state machines استعمال کریں۔ رقم کو integers کے طور پر محفوظ کریں۔

Source: https://dev.to/feidou/designing-saas-database-architecture-users-organizations-subscriptions-and-billing-df

Optional learning community: https://t.me/GyaanSetuAi