שני אורחים מצטרפים בדיוק באותו רגע כשנותר מקום אחד בתקרת 10 — מי נכנס?

התשובה הקצרה: לא, לא ב-11 אורחים. ברגע שאחד משני האורחים נכנס, הוא נכנס עד הסוף — מקבל guestId, סוד וגישה מלאה — ורק אז המערכת בודקת את הבקשה הבאה. זו לא הגנה ברמת מסד הנתונים כמו נעילה או אילוץ ייחודיות, אלא תוצאה של איך RegaRoll פרוס היום: שרת יחיד, תהליך Node.js אחד, בלי שני מקרים שרצים זה לצד זה.

מה בדיוק קורה בקוד כששני אורחים שולחים בקשת הצטרפות באותו רגע?

מסלול ההצטרפות (`/api/e/[code]/join`) עושה שתי פעולות נפרדות על מסד הנתונים: קודם סופר כמה אורחים כבר יש באירוע (`countEventGuests`), ואם המספר קטן מ-10 — כותב שורת אורח חדשה (`createGuest`). שתי הפעולות האלה אינן עטופות בטרנזקציה אחת, ואין בטבלת `guests` שום אילוץ שמגביל את מספר השורות לפי אירוע. בתיאוריה, אם שתי בקשות היו נכנסות באמת יחד, שתיהן יכולות לספור 9, שתיהן לעבור את הבדיקה, ושתיהן לכתוב שורה — וזה בדיוק המתכון למירוץ (race condition).

אז יש כאן מירוץ אמיתי שמאפשר ל-11 אורחים להיכנס בטעות?

לא, כי "יחד" כאן לא קיים בפועל. RegaRoll רץ כתהליך Node.js יחיד, ו-`better-sqlite3` (מנהל מסד הנתונים) הוא סינכרוני — כל פקודה חוסמת עד שהיא מסתיימת. בין הספירה לכתיבה ב-`join/route.ts` אין אפילו פקודת `await` אחת: שתי הפעולות רצות ברצף, בלי נקודת מעבר שבה התהליך יכול לעזוב ולהתחיל לטפל בבקשה השנייה. בקשה שנכנסת באותה מילישנייה פשוט מתחילה לרוץ מעט אחרי הראשונה, ורואה כבר את התוצאה המעודכנת.

זו הגנה אמיתית במסד הנתונים — נעילה, אילוץ ייחודיות, טרנזקציה?

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

מה היה קורה אם השרת היה רץ בכמה processes או workers, לא אחד?

אז כן, המירוץ היה אמיתי. שני processes נפרדים יכולים לקרוא את אותה ספירה (9) בדיוק באותו רגע ולכתוב במקביל, בלי שאחד מודע לשני — זה בדיוק מה שטרנזקציה או אילוץ ייחודיות קיימים כדי למנוע. אבל RegaRoll פרוס היום על שרת VPS בודד, קונטיינר Docker יחיד, Next.js ב-`next start` בלי PM2 ובלי cluster — כלומר process אחד, לא כמה. זו נקודה מבנית לזכור אם אי פעם יוחלט להוסיף שרת שני לעומסים: אז התקרה תצטרך הגנה אמיתית, לא רק מזל של ארכיטקטורה.

• שני אורחים שמצטרפים באותה שנייה ממש, במסלול חינמי שעומד על 9/10 — לא נגמר ב-11, אחד מהם פשוט נכנס שבריר שנייה לפני השני
• מה שמונע את זה היום: תהליך שרת יחיד + מנהל מסד נתונים סינכרוני, לא טרנזקציה או נעילה שתוכננו לשם כך
• אם ה-deployment ישתנה בעתיד לכמה processes או workers — ההגנה הזו נעלמת, ואז צריך תיקון אמיתי בקוד (אילוץ ייחודיות או טרנזקציה)
• לאורח ה-11 בכל מקרה: שגיאת `guest_limit` מיידית, בלי שום מסך ביניים או ניסיון נוסף להיכנס

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

למה בכלל יש תקרה של 10 אורחים, ולמה חשוב שהמספר הזה יהיה מדויק?

כי זה ההבדל האמיתי היחיד בין המסלולים — לא פיצ'ר שנפתח בתשלום. RegaRoll היא מצלמה חד־פעמית דיגיטלית לאירועים — ₪299 לאירוע, בלי אפליקציה — וההבדל בין המסלול החינמי לבתשלום הוא רק תקרת 10 האורחים ומשך השמירה (7 ימים מול 30), לא קיר הברכות, הרילסים או המצגת החיה. פירטנו את מה שקורה בפועל לאורח ה-11 ולאלו שכבר בפנים במאמר מגיעים לתקרת 10 האורחים באמצע האירוע — המאמר הזה בודק רק את השאלה הצרה יותר: מה קורה כששתי בקשות מגיעות בול באותו רגע.

מה האורח ה-11 בפועל חווה אם הוא מגיע בול כשהמקום האחרון נסגר?

חוויה חדה וברורה, לא תקיעה. הוא שולח את השם שלו, השרת בודק ורואה 10/10, והתגובה חוזרת תוך פחות משנייה עם שגיאת `guest_limit` וההודעה שהאירוע הגיע למגבלת המסלול החינמי. אין מסך טעינה שנתקע, אין ניסיון כפול שמייצר שורה כפולה — האורח פשוט לא נכנס, ומי שמנהל את האירוע רואה בדשבורד באנר מיידי שהתקרה התמלאה.

מה הקשר בין תקרת האורחים הזו לסיפור של צלם סושיאל ורילסים מהאורחים?

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