למה זה מאמר על כסף ולא על קוד
אני כותב את זה בשביל מייסדים ומנהלי מוצר, לא בשביל מפתחים. הסיבה פשוטה: שלוש ההחלטות שאתאר כאן נראות טכניות לגמרי, אבל כל אחת מהן קובעת כמה יעלה לכם להוסיף לקוח מספר 100, האם תוכלו למכור לארגון גדול, וכמה יעלה תיקון אם טעיתם.
ומה שמייחד אותן: הן זולות מאוד להחליט נכון בשבוע הראשון, ויקרות מאוד לשנות בשנה השנייה.
מה זה רב-דיירות בכלל
מערכת SaaS משרתת הרבה לקוחות שונים ("דיירים") על אותה תשתית. הלקוחות לא צריכים לדעת אחד על השני, ובוודאי לא לראות את הנתונים אחד של השני. השאלה הארכיטקטונית היא עד כמה עמוק הם מופרדים.
ההחלטה הראשונה: איך מפרידים נתונים
גישה א': מסד נתונים משותף, עמודת מזהה דייר
כל הלקוחות באותן טבלאות, ולכל שורה יש עמודה שאומרת למי היא שייכת. כל שאילתה מסננת לפיה.
יתרונות: הכי זול לתפעל, הכי פשוט לעדכן — שינוי סכמה אחד חל על כולם, ושרת אחד משרת אלף לקוחות.
חיסרון קריטי: שאילתה אחת ששכחו בה את הסינון חושפת נתונים של לקוח אחד לאחר. זו לא תקלה תיאורטית — זה סוג התקלה הכי נפוץ במערכות רב-דייריות, והנזק המוניטיני ממנה עצום.
ההגנה: אל תסמכו על כך שמפתחים יזכרו. אכפו את הסינון ברמת מסד הנתונים (בפוסטגרס: Row-Level Security), כך ששאילתה בלי הקשר דייר פשוט לא מחזירה כלום. זה שינוי של יום עבודה בהתחלה, ומונע את התקלה לתמיד.
גישה ב': סכמה נפרדת לכל דייר
אותו שרת מסד נתונים, אבל לכל לקוח מרחב שמות משלו.
יתרונות: בידוד חזק בהרבה, קל לגבות או למחוק לקוח בודד, ואפשר לתת ללקוח גדול שדות משלו.
חסרונות: כל שינוי סכמה צריך לרוץ על כל הסכמות — ב-500 לקוחות זו מיגרציה מסובכת. מעבר לכמה מאות סכמות, מסדי נתונים מתחילים לסבול.
גישה ג': מסד נתונים נפרד לכל דייר
יתרונות: בידוד מקסימלי, אפשר למקם נתונים במדינה מסוימת לפי רגולציה, ולקוח כבד לא משפיע על אחרים.
חסרונות: העלות התפעולית מזנקת, וכל תהליך תחזוקה הופך למורכב. זה הגיוני ל-B2B עם עשרות לקוחות גדולים — לא למוצר עם אלפי משתמשים קטנים.
מה אני ממליץ בפועל
ל-90% מהמוצרים: גישה א' עם אכיפה ברמת מסד הנתונים. היא הזולה ביותר, וההגנה הנכונה סוגרת את החיסרון המרכזי שלה.
החוכמה היא לבנות אותה כך שאפשר יהיה להוציא לקוח בודד למסד נפרד בעתיד בלי לשכתב את המערכת. בפועל זה אומר: לעולם אל תפזרו את הסינון ידנית בקוד — רכזו את הגישה לנתונים בשכבה אחת. אם עשיתם את זה, מעבר לגישה ג' ללקוח ארגוני אחד הוא פרויקט של שבועות, לא של רבעון.
ההחלטה השנייה: מודל ההרשאות
זו ההחלטה שהכי מזלזלים בה, והכי כואב לתקן.
הרבה מוצרים מתחילים עם שני תפקידים: מנהל ומשתמש. זה מספיק לשנה. אחר כך מגיע לקוח ואומר: "אני רוצה שרואה החשבון יראה רק את המספרים, שהמנהל האזורי יראה רק את הסניפים שלו, ושקבלן חיצוני יראה פרויקט אחד."
אם בניתם על שני תפקידים קשיחים, התשובה היא שכתוב של כל שכבת ההרשאות — שנוגעת כמעט בכל שורת קוד במערכת.
ההמלצה: גם אם אתם משיקים עם שני תפקידים, בנו את המנגנון סביב הרשאות ולא סביב תפקידים. תפקיד הוא אוסף של הרשאות, והקוד בודק הרשאה ("האם למשתמש הזה מותר לצפות בדוח פיננסי?") ולא תפקיד ("האם הוא מנהל?"). ההפרש בשלב הבנייה הוא כמה ימים. ההפרש בשלב התיקון הוא חודשים.
ההחלטה השלישית: איך נראה לוג הפעילות
ברגע שתנסו למכור ללקוח ארגוני, השאלה "מי שינה את זה ומתי" תעלה. אם לא תכננתם לזה, התשובה תהיה "אין לנו דרך לדעת", וזו לרוב סוף העסקה.
לוג פעילות שנבנה מההתחלה הוא כמה ימי עבודה. לוג שמוסיפים בדיעבד למערכת קיימת דורש נגיעה בכל פעולה שמשנה נתונים, והוא לא רטרואקטיבי — כלומר אין לכם היסטוריה, בדיוק כשהיא נדרשת.
ומה לא צריך להחליט מראש
כדי לא ליצור רושם מוטעה — רוב הדברים אפשר ואף כדאי לדחות:
- מיקרו-שירותים. כמעט אף מוצר בשלב מוקדם לא צריך אותם. הם מוסיפים מורכבות תפעולית עצומה כדי לפתור בעיה שעוד אין לכם.
- סקיילינג לעומסים. אל תבנו לעשרה מיליון משתמשים לפני שיש לכם עשרה. תשתית מנוהלת מודרנית תיקח אתכם רחוק מאוד.
- בחירת שפה או פריימוורק "לנצח". קוד מוחלף. סכמת נתונים והרשאות — הרבה פחות.
- מיטוב ביצועים מוקדם. תמדדו קודם. רוב ההנחות על מה איטי מתבררות כשגויות.
הכלל: מה שקשה לשנות — תכננו. מה שקל לשנות — אל תתכננו. בידוד נתונים, הרשאות ולוג הם בקבוצה הראשונה. כמעט כל השאר בשנייה.
איך זה נראה בפרויקט אמיתי
בפרויקטים שלנו שלוש ההחלטות האלה נסגרות בשלב האפיון, לפני שנפתח עורך קוד. זה מוסיף כמה ימים לתחילת הפרויקט, ובכל פרויקט שהגיע לשלב שבו יש לקוח ארגוני זה החזיר את עצמו פי כמה.
שאר המערכת נבנית לפי גישת ה-MVP — מינימלית, מהירה, ומורחבת לפי מה שמשתמשים באמת עושים.
שורה תחתונה
אם אתם בונים SaaS, ודאו שהצוות שלכם יכול לענות על שלוש שאלות לפני שמתחילים: איך מופרדים נתונים בין לקוחות ומה אוכף את זה, האם ההרשאות מבוססות תפקידים קשיחים או הרשאות גמישות, והאם יש לוג פעילות. אם התשובות מעורפלות — עצרו יומיים. זה יומיים שחוסכים רבעון.
להמשך: מדריך פיתוח SaaS, מדף מול מותאם, ומה זה MVP. בונים מערכת? כאן פרטי השירות או דברו איתי.
נכתב על ידי אביתר אדלר, CTO ב-FlowDev.
