האתגר
מה עמד לפני Quick?
Quick הפעילה מערכת הזמנת חדרי ישיבות וחללי עבודה שסבלה מ-Double Booking תכופים — שתי הזמנות מקבילות לאותה שעה ואותו חלל. הסיבה: הארכיטקטורה הישנה לא טיפלה נכון ב-Race Conditions, ולא הייתה שכבת Real-Time Availability שמונעת בחירת חלל שכבר נתפס.
הפתרון
מה בנינו
בנינו Backend עם Pessimistic Locking ברמת Database למניעת Race Conditions, ו-WebSocket Server שמשדר עדכוני זמינות לכל הלקוחות בו-זמנית. כשמשתמש בוחר חלל, הוא מקבל Soft Lock ל-90 שניות שמונע הזמנות מקבילות. כל ה-Transaction Logic מגובה ביחידות בדיקה שמדמות עומס Concurrent.
תוצאות
מה השגנו יחד
✓אפס אירועי Double-Booking ב-8 חודשים מאז ההשקה
✓עדכון זמינות מגיע לכל הלקוחות תוך 200ms דרך WebSocket
✓המערכת עמדה בעומס של 1,200 הזמנות בשעת שיא אחת