Multi-tenancy זו החלטה שקובעת את כל הארכיטקטורה של ה-SaaS שלכם. תבחרו לא נכון – תשלמו על זה 5 שנים. הנה המדריך המעשי מבניית פלטפורמות אמיתיות.

3 הגישות ל-Multi-tenant

Shared Database, Shared Schema: כל הלקוחות באותו DB, באותם טבלאות, מסוננים ע”פ tenant_id. הכי חסכוני. הכי גמיש. אבל הכי מסוכן אם עושים bugs.

Shared Database, Separate Schema: DB אחד, schema לכל לקוח. Isolation טוב יותר. עולה יותר. סבוך יותר ל-migrations.

Separate Database: DB לכל לקוח. Isolation מקסימלי. יקר. סבוך. מתאים לחברות עם צרכי compliance קיצוניים.

Row-Level Security – הגישה הפופולרית ב-Postgres

ב-99% מהפרויקטים בחרנו Shared Database, Shared Schema עם Postgres Row-Level Security. הרעיון: כל שורה מוגנת ברמת ה-DB לפי tenant_id. גם אם מפתח שוכח סינון בקוד – Postgres יסנן אוטומטית.

איך מפעילים: (1) ALTER TABLE table_name ENABLE ROW LEVEL SECURITY; (2) יוצרים policy שמגבילה לפי current_tenant. (3) בכל connection – SET tenant_id. גמור.

איך בונים tenant isolation שלא ידלוף

הבעיה הכי נפוצה: bug אחד = כל לקוחות רואים דאטה של כולם. איך למנוע?

(1) RLS ב-DB level. (2) Middleware שמזריק tenant_id בכל query. (3) Testing עם fixtures ריאליים – יצירת 3 tenants ובדיקה שאף אחד לא רואה את השני. (4) Audit logs – מי גישה לאיזה נתונים.

Onboarding של tenant חדש

בפרויקטים שלנו tenant חדש נכנס תוך 60 שניות. איך? Provisioning אוטומטי: יצירת tenant record, יצירת admin user, קונפיגורציה ברירת מחדל, welcome email עם קישור לפלטפורמה.

Custom domains ל-tenants

לקוחות רוצים custom domain (client.mycompany.com). הפתרון הפשוט: Cloudflare SSL for SaaS. הם מטפלים ב-SSL certificates אוטומטית. אתם רק צריכים routing.

Backup ו-restore ל-tenant בודד

כשלקוח מבקש לשחזר את המידע שלו מלפני שבוע – איך עושים בלי לפגוע בכולם?

הגישה: pg_dump עם –where לפי tenant_id. Backup יומי. אם לקוח מבקש restore – יוצרים sandbox DB, restore, מבקשים אישור, ואז merge. תהליך של שעתיים.

מבוסס על פרויקטים אמיתיים

המדריך הזה מבוסס על עבודה עם:

• Platforma365
• Podd

קריאה נוספת

אם המדריך הזה עזר לכם, אולי תרצו לקרוא גם על פיתוח SaaS מותאם – המדריך המקיף שלנו לתחום.