בסיס קוד אחד, מאות דיירים, אפס דליפת נתונים — היסוד של כל עסק SaaS סקלבילי.

אתם בונים פלטפורמה שמשרתת מספר לקוחות מפריסה אחת. כל לקוח מצפה לנתונים מבודדים, חוויות ממותגות, וחיוב לפי דייר — אבל אתם לא יכולים להרשות לעצמכם להפעיל תשתית נפרדת עבור כל אחד. אתם צריכים את הכלכלה של תשתית משותפת עם הבטחות הבידוד של מערכות ייעודיות. זהו המתח הבסיסי של ארכיטקטורת SaaS, וטעייה במודל הבידוד בשלב מוקדם היא אחת הטעויות היקרות ביותר בפיתוח פלטפורמות.
Explore more design patterns and system architectures
אדריכלים שלנו יכולים לעזור לך לעצב ולבנות מערכות תוך שימוש בדפוס זה לדרישות הספציפיות שלך.
צרו קשרארכיטקטורת SaaS מרובת דיירים מספקת הפרדה לוגית או פיזית בין דיירים תוך שיתוף משאבי compute, storage ו-networking בסיסיים. התבנית כוללת הקצאת דיירים, בידוד נתונים, ניהול פיצ'רים, מדידת חיובים והתאמה אישית של white-label. החלטת התכנון המרכזית היא מודל הבידוד: מסד נתונים משותף עם row-level security (RLS), schema-per-tenant או database-per-tenant. כל מודל מחליף חוזק בידוד מול מורכבות תפעולית ויעילות עלויות.
המערכת מאורגנת לשלוש שכבות. ה-tenant-aware gateway מטפל באימות, זיהוי דייר (באמצעות subdomain, JWT claim או API key) וניתוב בקשות. שכבת היישום פועלת כולה בהקשר של הדייר — כל שאילתה, כל cache key, כל הודעת queue מוגדרת לדייר המזוהה. שכבת הנתונים אוכפת בידוד ברמת האחסון באמצעות מדיניות row-level security (RLS), connection pooling לכל דייר, ו-partitioning מוצפן במנוחה (encrypted-at-rest).
tenant_id. עבור schema-per-tenant: ניתוב חיבורים דינמי עם ניהול connection pool. עבור database-per-tenant: אוטומציית הקצאה עם Terraform/Pulumiacme.yourapp.com) נקיים יותר עבור מוצרי white-label ומאפשרים אישורי TLS לכל דייר. Path-based (yourapp.com/acme/) פשוט יותר ליישום ונמנע ממורכבות wildcard DNS. MicrocosmWorks (MW) ממליצה על זיהוי subdomain עבור B2B SaaS עם דרישות white-label, ו-path-based עבור כלים פנימיים מרובי דיירים.tenant_id. זה נשמע מובן מאליו, אך התנגשויות cache key בין דיירים הן אחת מבאגים ה-multi-tenant הנפוצים ביותר. אנו אוכפים זאת באמצעות cache key factory שמצרף אוטומטית את הקשר הדייר.| שכבה | טכנולוגיות |
|---|---|
| Compute | Node.js (NestJS), Python (FastAPI), במיכלים על ECS Fargate או Kubernetes |
| נתונים | PostgreSQL עם RLS, Redis (בסקופ דייר), S3 (דליים מחולקים לפי דייר) |
| זהות | Clerk, Auth0, או Okta עם ארגונים בסקופ דייר |
| חיוב | Stripe Connect (מודל marketplace), Stripe Billing (מנויים מדודים) |
| נראות (Observability) | Datadog עם תגיות במימד דייר, structured logging עם tenant_id בכל רשומה |
| השתמש כאשר | הימנע כאשר |
|---|---|
| בונים פלטפורמת B2B המשרתת 10+ לקוחות מתשתית משותפת | כל לקוח דורש תשתית ייעודית לחלוטין (ציות/חוזית) |
| אתם זקוקים למיתוג white-label, דומיינים מותאמים אישית, ובקרת פיצ'רים לכל דייר | יש לכם פחות מ-3 לקוחות — פריסה פשוטה יותר לכל לקוח עשויה להספיק |
| תמחור מבוסס שימוש או מדורג דורש מדידה לכל דייר | המוצר הוא אפליקציית צרכנים עם חשבונות ברמת משתמש, לא דיירים ברמת ארגון |
| אתם רוצים pipeline פריסה אחד, ערימת ניטור אחת, on-call rotation אחד | לדיירים יש סכמות או לוגיקה עסקית שונות באופן מהותי (לא רק תצורה) |
MicrocosmWorks (MW) מתייחסת ל-multi-tenancy כ-cross-cutting concern, לא כתכונה. אנו מיישמים הפצת הקשר דייר ברמת ה-middleware כך שקוד היישום לעולם אינו מסנן ידנית לפי דייר — זה נאכף על ידי ה-framework. יישומי ה-RLS שלנו כוללים חבילות בדיקה אוטומטיות שמנסות גישת נתונים בין דיירים בכל ריצת CI. בנינו פלטפורמות מרובות דיירים המשרתות 500+ דיירים על תשתית משותפת ללא אירועי דליפת נתונים, והעברנו monoliths של דייר יחיד לארכיטקטורות מרובות דיירים באמצעות תבנית strangler fig.
מודלים לא מריצים את עצמם. ה-Pipeline שמכשיר, מאמת, פורס ומנטר את המודלים שלך הוא המוצר האמיתי – המודל הוא רק תוצר אחד.
הבחירה האופטימלית תלויה בדרישות בידוד הדיירים (tenant isolation) ובסקאלה (scale) שלכם. MicrocosmWorks ממליצה בדרך כלל על גישת מסד נתונים משותף עם סכמות נפרדות (shared-database, separate-schema) עבור רוב מוצרי B2B SaaS, מכיוון שהיא מאזנת בין יעילות עלויות (cost efficiency) לבין בידוד נתונים (data isolation). יחד עם זאת, אנו מיישמים מודל של מסד נתונים לכל דייר (database-per-tenant) עבור לקוחות בתעשיות מפוקחות כמו בריאות או פיננסים, שבהן הפרדת נתונים קפדנית (strict data segregation) היא חובה. הארכיטקטים שלנו מעריכים את צרכי הציות (compliance needs), מספר הדיירים הצפוי ודפוסי השאילתות (query patterns) לפני שהם ממליצים על מודל הדיירות (tenancy model) הנכון.
MicrocosmWorks מיישמת הגבלת קצב (rate limiting) מודעת לדיירים, איגום חיבורים (connection pooling) עם מכסות לכל דייר (per-tenant quotas), ובידוד משאבים בשכבת המחשוב (compute layer) כדי למנוע בעיות 'שכן רועש' (noisy-neighbor problems). אנו משתמשים בטכניקות כמו תורים הוגנים משוקללים (weighted fair queuing) ושכבות מטמון ספציפיות לדייר (tenant-specific caching tiers) כך שקפיצה פתאומית מלקוח אחד לא תגרום לשיהוי (latency) עבור אחרים. עבור דיירים ברמת Enterprise, אנו יכולים להקצות מחיצות מחשוב ייעודיות (dedicated compute partitions) תוך שמירה על מישור הבקרה המשותף (shared control plane) ללא פגע.
MicrocosmWorks מציעה שירותי תכנון ויישום ארכיטקטורה בתעריפי ייעוץ הנעים בין 15 ל-45 דולר לשעה, בהתאם למורכבות ולבכירות הצוות הנדרשת. פרויקט אופייני של ארכיטקטורת SaaS רב-דיירים – המכסה עיצוב מסד נתונים, בידוד דיירים (tenant isolation), אימות (authentication) וצינורות פריסה (deployment pipelines) – נמשך 8-16 שבועות עם צוות רב-תחומי (cross-functional team). אנו מתמחרים כל פרויקט עם שלב גילוי (discovery phase) במחיר קבוע, כך שיש לכם שקיפות עלויות מלאה לפני התחייבות לבנייה.
MicrocosmWorks בונה צינורות אוטומטיים להקצאת משאבים לדיירים (automated tenant provisioning pipelines) המטפלים ביצירת סכמה (schema creation), הגדרת DNS, אתחול Feature Flags ופריסת נתוני Seed בתוך דקות מרגע הרשמה חדשה. אנו משתמשים בכלי Infrastructure-as-Code כמו Terraform או Pulumi בשילוב עם תהליכי עבודה מונעי אירועים (event-driven workflows) כך שכל דייר חדש מקבל סביבה מוגדרת במלואה ללא התערבות ידנית. גישה זו מאפשרת ללקוחותינו להתרחב מ-10 דיירים ל-10,000 ללא שינוי בתהליך הקליטה (onboarding process).
MicrocosmWorks מיישמת שכבת התאמה אישית מונחית-תצורה (configuration-driven customization layer) באמצעות Feature Flags, מטא-דאטה ספציפי לדייר (tenant-specific metadata) וארכיטקטורת פלאגינים (plugin architecture) המאפשרת התנהגות פר-דייר ללא פיצול קוד (code branching). אנו מעצבים נקודות הרחבה (extensibility points) בשכבות עיצוב ממשק המשתמש (UI theming), מנוע תהליכי העבודה (workflow engine) והאינטגרציה, כך שלדיירים יכולים להיות מיתוג ייחודי (unique branding), כללים עסקיים (business rules) וחיבורי צד שלישי (third-party connections), כולם מנוהלים באמצעות תצורה. זה שומר על צוות ההנדסה שלכם מתחזק בסיס קוד יחיד, תוך תמיכה בדרישות לקוחות מגוונות.