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

אתם בונים פלטפורמה שמשרתת מספר לקוחות מפריסה אחת. כל לקוח מצפה לנתונים מבודדים, חוויות ממותגות, וחיוב לפי דייר — אבל אתם לא יכולים להרשות לעצמכם להפעיל תשתית נפרדת עבור כל אחד. אתם צריכים את הכלכלה של תשתית משותפת עם הבטחות הבידוד של מערכות ייעודיות. זהו המתח הבסיסי של ארכיטקטורת SaaS, וטעייה במודל הבידוד בשלב מוקדם היא אחת הטעויות היקרות ביותר בפיתוח פלטפורמות.
Explore more design patterns and system architectures
הבחירה האופטימלית תלויה בדרישות בידוד הדיירים שלך ובקנה המידה. MicrocosmWorks ממליצה בדרך כלל על גישת shared-database, separate-schema עבור רוב מוצרי B2B SaaS, מכיוון שהיא מאזנת יעילות עלויות עם בידוד נתונים, אף על פי שאנו מיישמים database-per-tenant עבור לקוחות בתעשיות מפוקחות כמו בריאות או פיננסים שבהן הפרדת נתונים קפדנית נדרשת. האדריכלים שלנו מעריכים את צרכי הציות שלך, מספר הדיירים הצפוי, ותבניות שאילתות לפני המלצה על מודל הדיירות הנכון.
MicrocosmWorks מיישמת הגבלת קצב (rate limiting) מודעת-דייר, איגום חיבורים (connection pooling) עם מכסות לכל דייר, ובידוד משאבים בשכבת החישוב כדי למנוע בעיות של 'שכן רועש'. אנו משתמשים בטכניקות כמו תור הוגן משוקלל (weighted fair queuing) ושכבות מטמון (caching tiers) ספציפיות לדייר, כך שזינוק פתאומי מלקוח אחד לא יתגלגל לאיחוי (latency) עבור אחרים. עבור דיירים ברמת ארגון (enterprise-tier), אנו יכולים להקצות מחיצות חישוב ייעודיות תוך שמירה על מישור הבקרה המשותף (shared control plane) ללא פגע.
חברת MicrocosmWorks מציעה שירותי תכנון והטמעת ארכיטקטורה בתעריפי ייעוץ הנעים בין $15-$45 לשעה, בהתאם למורכבות ולבכירות הצוות הנדרשת. פרויקט ארכיטקטורת SaaS מרובת דיירים טיפוסי – המכסה database design, tenant isolation, authentication, ו-deployment pipelines – נמשך 8-16 שבועות עם צוות רב-תחומי. אנו מגדירים את היקף כל פרויקט עם discovery phase במחיר קבוע, כך שתהיה לך שקיפות מלאה לגבי העלויות לפני התחייבות לבנייה.
MicrocosmWorks בונה צינורות אוטומטיים לאספקת משאבים לדיירים המטפלים ביצירת סכימה, תצורת DNS, אתחול דגלי תכונות, ופריסת נתוני אתחול תוך דקות ספורות מהרשמה חדשה. אנו משתמשים בכלי Infrastructure-as-Code כמו Terraform או Pulumi בשילוב עם תהליכי עבודה מונעי-אירועים, כך שכל דייר חדש מקבל סביבה מוגדרת במלואה ללא התערבות ידנית. גישה זו מאפשרת ללקוחותינו להתרחב מ-10 דיירים ל-10,000 מבלי לשנות את תהליך הקליטה.
MicrocosmWorks מיישמת configuration-driven customization layer באמצעות feature flags, tenant-specific metadata, ו-plugin architecture המאפשרת per-tenant behavior ללא code branching. אנו מתכננים extensibility points ב-UI theming, ב-workflow engine, וב-integration layers, כך של-tenants יוכלו לקבל branding ייחודי, business rules, ו-third-party connections – כולם מנוהלים באמצעות configuration. זה מאפשר ל-engineering team שלכם לתחזק single codebase תוך תמיכה בדרישות לקוח מגוונות.
אדריכלים שלנו יכולים לעזור לך לעצב ולבנות מערכות תוך שימוש בדפוס זה לדרישות הספציפיות שלך.
צרו קשרארכיטקטורת 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 שמכשיר, מאמת, פורס ומנטר את המודלים שלך הוא המוצר האמיתי – המודל הוא רק תוצר אחד.