פלטפורמה דו-צדדית לפדרציית אומנויות לחימה

מה זה

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

הבעיה

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

החלק הקשה

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

הלקח השני היה משמעת של שמירת נתונים. בהתחלה נתוני המתאמנים חיו ב-state של הקומפוננטה ונעלמו ברענון. העברתם ל-Postgres, מאחורי migrations מסודרות, לא הייתה פיצ׳ר. זו הייתה הנקודה שבה הדבר הפסיק להיות אב-טיפוס.