MicrocosmWorksחדשנות ותכנון קוסמוס דיגיטלי
אודותצור קשר
MicrocosmWorksמחדשים ומתכננים קוסמוס דיגיטלי

מספקים פתרונות IT חשובים. אנו נלהבים מטכנולוגיה, אבטחה ועוזרים לעסקים לצמוח באמצעות תשתית IT אמינה וחדשנית.

[email protected]
+91 7011868196
New Delhi, India

מרכז צמיחה AI

מרכז AIחדשנות סטארטאפמאיץ ארגוני

פתרונות

כל הפתרונותאפליקציות בריאות וכושרפלטפורמת וידאו AIפיתוח סוכני AI

משאבים

תובנותמדריכי תעשייהתוכניות מקרה שימושתבניות ארכיטקטורהמחקרי מקרה

חברה

אודותינוצור קשרהעבודה שלנו

שירותים

ייעוץ דיגיטליתשתית ענןפיתוח SaaSפיתוח AIטכנולוגיית וידאו
פיתוח ERPהתאמה אישית של Zohoפיתוח Odooאינטגרציה של Salesforceפיתוח CRM מותאם אישית
אינטגרציה של QuickBooksפתרונות IoTפיתוח בלוקצ'יין
ייעוץ סייברתמיכה טכנית - L3

© 2026 MicrocosmWorks. כל הזכויות שמורות.

מדיניות פרטיותתנאי שירות
חזרה לתבניות ארכיטקטורה
ApplicationAdvanced

ארכיטקטורת SaaS מרובת דיירים

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

June 22, 2026
|
3 topics covered
דיון בארכיטקטורה זו
multi-tenant-saas-architecture.webp
Application
Category
Advanced
Complexity
Healthcare, EdTech
Industries
3+
Technologies

מתי צריך את זה

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

סקירת תבנית

Related Architecture Patterns

Explore more design patterns and system architectures

event-driven-microservices.webp
Application

מיקרו-שירותים מונחי אירועים

נתק הכל. תן לשירותים לתקשר באמצעות אירועים, לא ציפיות לגבי זמינות הדדית.

EnterpriseView
ai-ml-pipeline-architecture.webp

האם אתה זקוק לעזרה בהטמעת ארכיטקטורה זו?

אדריכלים שלנו יכולים לעזור לך לעצב ולבנות מערכות תוך שימוש בדפוס זה לדרישות הספציפיות שלך.

צרו קשר

ארכיטקטורת 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 Management Service): מטפל בהקצאה, תהליכי onboarding, מיפוי דומיינים מותאמים אישית, תצורת נושא/מיתוג, ו-feature flags לכל דייר. חושף API פנימי עבור אירועי מחזור חיי דייר (נוצר, הושעה, נמחק)
  • מפיץ הקשר דייר (Tenant Context Propagator): Middleware שמזהה את זהות הדייר מהבקשה (subdomain, JWT, header) ומחדיר את הקשר הדייר לכל קריאה במורד הזרם — חיבורי מסד נתונים, cache keys, הודעות queue, רשומות log
  • מנוע בידוד נתונים (Data Isolation Engine): מיישם את מודל הבידוד שנבחר. עבור RLS: מדיניות PostgreSQL שמסננת כל שאילתה לפי tenant_id. עבור schema-per-tenant: ניתוב חיבורים דינמי עם ניהול connection pool. עבור database-per-tenant: אוטומציית הקצאה עם Terraform/Pulumi
  • שירות חיוב ומדידה (Billing & Metering Service): מעקב שימוש מונחה אירועים עם צבירה לפי דייר. משתלב עם Stripe Connect או מנועי חיוב מותאמים אישית. תומך במודלי תמחור מרובים (per-seat, מבוסס שימוש, tiered, היברידי)

החלטות תכנון ופשרות

RLS מול Schema-per-Tenant מול Database-per-Tenant
MicrocosmWorks (MW) נוטה כברירת מחדל ל-RLS (מסד נתונים משותף, row-level security) עבור רוב מוצרי ה-SaaS. זהו הפשוט ביותר לתפעול — נתיב מיגרציה אחד, connection pool אחד, אסטרטגיית גיבוי אחת. Schema-per-tenant הגיוני כאשר דיירים זקוקים להרחבות סכימה מותאמות אישית (נדיר) או כאשר דרישות רגולטוריות דורשות בידוד בר הוכחה. Database-per-tenant שמור לעסקאות ארגוניות שבהן הלקוח דורש חוזית תשתית ייעודית. שילחנו את כל השלוש — הבחירה תלויה בעמדת הציות שלכם ובמספר הדיירים.
זיהוי דייר מבוסס Subdomain מול Path
Subdomains (acme.yourapp.com) נקיים יותר עבור מוצרי white-label ומאפשרים אישורי TLS לכל דייר. Path-based (yourapp.com/acme/) פשוט יותר ליישום ונמנע ממורכבות wildcard DNS. MicrocosmWorks (MW) ממליצה על זיהוי subdomain עבור B2B SaaS עם דרישות white-label, ו-path-based עבור כלים פנימיים מרובי דיירים.
Feature Flags משותפים מול תצורת Per-Tenant
אנו משתמשים במערכת feature flags דו-שכבתית: flags גלובליים שולטים בהפצה ברחבי הפלטפורמה, ו-overrides ברמת הדייר מאפשרים לכם להפעיל תכונות בטא עבור לקוחות ספציפיים או להשבית תכונות עבור דיירים בתוכניות נמוכות יותר. Edge Config או LaunchDarkly מגבים זאת עם קריאות בתת-מילישנייה.
Caching מודע דייר
כל cache key חייב להיות מוגדר ל-tenant_id. זה נשמע מובן מאליו, אך התנגשויות cache key בין דיירים הן אחת מבאגים ה-multi-tenant הנפוצים ביותר. אנו אוכפים זאת באמצעות cache key factory שמצרף אוטומטית את הקשר הדייר.

בחירות טכנולוגיות

שכבהטכנולוגיות
ComputeNode.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.

תוכניות דומות

  • SaaS לאימון בריאות מרובה דיירים (Multi-Tenant Wellness Coaching SaaS) — בידוד RLS עם מיתוג white-label לעסקי אימון
  • פלטפורמת למידה מותאמת אישית מונחית AI (AI-Driven Personalized Learning Platform) — EdTech מרובה דיירים עם ספריות תוכן לכל דייר
  • פלטפורמת ניהול אירועים וכרטוס (Event Management & Ticketing Platform) — דייר לכל מארגן עם כרטוס בזמן אמת
  • מנוע חיוב ומנויים מרובה דיירים (Multi-Tenant Billing & Subscription Engine) — עמוד השדרה של החיוב עבור פלטפורמות מרובות דיירים

מקרי בוחן קשורים

  • SaaS הדרכת VR מרובה דיירים (VR Training Multi-Tenant SaaS) — פלטפורמה מרובת דיירים עם תוכן VR ואנליטיקה בסקופ דייר
  • פלטפורמת צ'אט AI (AI Chat Platform) — SaaS צ'אט מרובה מודלים עם ניהול API key לכל דייר ועמידה ב-GDPR
Related Technologies
SaaS DevelopmentCloud SolutionsAI Development
AI / Data

ארכיטקטורת Pipeline של AI/ML

מודלים לא מריצים את עצמם. ה-Pipeline שמכשיר, מאמת, פורס ומנטר את המודלים שלך הוא המוצר האמיתי – המודל הוא רק תוצר אחד.

EnterpriseView
cloud-native-infrastructure.webp
Infrastructure

תשתית Cloud-Native

תשתית שמנוהלת בגרסאות, נבדקת ונפרסת כמו קוד יישום — כי הפלטפורמה שלך אמינה רק כמו מה שנמצא מתחתיה.

EnterpriseView

שאלות נפוצות

הבחירה האופטימלית תלויה בדרישות בידוד הדיירים (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), כולם מנוהלים באמצעות תצורה. זה שומר על צוות ההנדסה שלכם מתחזק בסיס קוד יחיד, תוך תמיכה בדרישות לקוחות מגוונות.