מסמך טכני ללקוח — סקירה ברמה גבוהה

איך המערכת בנויה
מאחורי הקלעים.

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

איפיון וארכיטקטורהפלטפורמת SaaS רב-דיירית (multi-tenant) המנוהלת בענן, ללא צורך בהתקנה או בתחזוקת שרתים בצד הלקוח.

01 · תקציר

מה המערכת עושה, ולמי מיועדת

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

מודל רב-דיירי

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

החלטה אוטומטית + בקרה אנושית

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

שירות מנוהל בענן

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

02 · ארכיטקטורה

ארבע שכבות, הפרדה ברורה של אחריות

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

שכבת משתמש

דפדפן בעמדת השירות, בדפדפן הלקוח או בטלפון הנייד. אין צורך בהתקנת אפליקציה.

שכבת אפליקציה

שרת ה-Next.js מריץ את כל הלוגיקה העסקית: הרשאות, ולידציה, כללי זכאות ותקשורת עם השירותים החיצוניים.

שכבת נתונים

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

שירותים חיצוניים

ספק ה-AI לחילוץ חשבוניות ושירות ה-SMS מופעלים אך ורק מצד השרת, עם מפתחות גישה שאינם נחשפים לדפדפן.

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

03 · מחסנית טכנולוגית

באילו טכנולוגיות נעשה שימוש

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

צד לקוח (Frontend)

Next.js (App Router)מסגרת React מודרנית לרינדור בצד שרת ובצד לקוח, עם ניתוב מבוסס תיקיות.
Reactספריית ממשק המשתמש שעליה בנויים כל המסכים.
TypeScriptשכבת טיפוסים סטטית שמפחיתה שגיאות ומייצבת את הפיתוח לאורך זמן.

צד שרת ואירוח

Vercelפלטפורמת אירוח וענן (serverless) שמריצה את השרת ופורסת עדכונים אוטומטית.
Route Handlers / Server Actionsלוגיקת השרת (בדיקת הרשאה, ולידציה, כללי זכאות) רצה בצד שרת בלבד — אף פעם לא בדפדפן.
Zodולידציה קפדנית של כל קלט שמגיע מהדפדפן לפני שהוא נוגע במסד הנתונים.

מסד נתונים ואחסון

Supabase (PostgreSQL מנוהל)מסד נתונים יחסי, מנוהל ומגובה, עם בקרת גישה ברמת השורה (ר' בהמשך).
Storage פרטיאחסון קבצים ייעודי לתמונות חשבוניות, לא ציבורי, עם קישורי צפייה זמניים בלבד.
Edge Functionsפונקציות שרת קצרות-חיים לפעולות רגישות (אימות SMS, יצירת משתמשים).

אינטגרציות חיצוניות

ספק בינה מלאכותית לחילוץ נתונים (OCR)קורא חשבונית שצולמה ומציע מספר, תאריך, סכום וסוג מסמך — הצעה בלבד, לא קביעה סופית.
שירות SMSשליחת קוד אימות ללקוחות והודעות עדכון לצוות, ללא חשיפת פרטי הקוד ללקוח בממשק.

פיתוח ובקרת איכות

בקרת גרסאות (Git)כל שינוי בקוד מתועד, ניתן למעקב ולשחזור.
בדיקות אוטומטיות (Vitest)בדיקות יחידה לכללי הזכאות וההרשאות שרצות לפני כל פריסה.
פריסה רציפה (CI/CD)כל עדכון עובר בנייה ובדיקות אוטומטיות לפני שהוא מגיע לסביבת הייצור.

04 · פרוטוקולים ותקשורת

איך רכיבי המערכת מדברים ביניהם

HTTPS / TLS

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

REST ו-RPC מאובטחים

הדפדפן פונה לשרת בקריאות API סטנדרטיות; השרת פונה למסד הנתונים דרך פונקציות מבוקרות (RPC) שבודקות הרשאה בכל קריאה.

Webhooks / SMS Gateway

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

קישורי גישה זמניים (Signed URLs)

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

עוגיות מאובטחות (HttpOnly Cookies)

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

ולידציה בצד שרת

כל קלט (טפסים, קבצים, מספרי טלפון) נבדק ומנורמל בצד השרת לפני שהוא נשמר — לא ניתן לעקוף בדיקה על ידי שינוי בדפדפן.

05 · אבטחה ופרטיות

עקרונות ההגנה על הנתונים

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

הצפנה בתעבורהכל תקשורת בין הדפדפן לשרת ובין השרת למסד הנתונים מוצפנת (HTTPS/TLS).
אימות מבוסס טוקןהתחברות צוות מבוססת טוקן אימות (JWT) בעוגייה מאובטחת שאינה נגישה לקוד צד לקוח (httpOnly).
בקרת גישה ברמת מסד הנתוניםRow-Level Security — כל שאילתה נבדקת מול הרשאת המשתמש והדייר (הקניון) שלו ברמת מסד הנתונים עצמו, לא רק בקוד האפליקציה.
אימות דו-שלבי ללקוחלקוחות מזדהים באמצעות קוד חד-פעמי הנשלח ב-SMS למספר הטלפון שלהם, ללא צורך בסיסמה או חשבון.
אחסון מוגבל בזמןתמונות חשבוניות נשמרות באחסון פרטי ונמחקות ברגע שההרשמה אושרה או נדחתה ידנית.
בידוד בין ארגוניםכל רשומה במערכת משויכת לדייר (קניון/ארגון) ספציפי; המבנה מונע דליפת מידע בין דיירים שונים על אותה תשתית.

06 · מבנה ריבוי-דיירים

איך מבודדים בין ארגונים וקניונים

המערכת פועלת במודל היררכי: מנהל־על ← ארגון ← קניון ← חנויות ועמדות. הבידוד בין דיירים אינו רק הסכמי אלא נאכף ברמת מסד הנתונים.

ארגון

גוף עסקי שיכול להפעיל קניון אחד או יותר תחת אותו חשבון.

קניון (דייר)

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

עמדות וחנויות

כל קניון מנהל את עמדות השירות והחנויות המשתתפות שלו באופן עצמאי.

הרשאות לפי תפקיד

כל משתמש מקבל תפקיד בקניון ספציפי (עמדה, מנהל, סוקר וכו׳); מנהל־העל בלבד רואה תמונה כוללת בין קניונים.

ניתוב לפי דייר

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

תצורה עצמאית

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

07 · היקפי עבודה

באילו היקפים המערכת יכולה לעבוד

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

היקפים נוכחיים — קו בסיס
פרמטר	מצב נוכחי
מספר ארגונים/קניונים	אין תלות בתשתית נפרדת — הוספת קניון היא רשומת נתונים, לא פריסה חדשה
עמדות שירות במקביל	כל עמדה היא בקשת שרת עצמאית; שכבת האפליקציה מתרחבת אוטומטית לפי עומס
הרשמות ביום	מתאים כיום לנפח של אלפי הרשמות ביום ללא שינוי תשתית
חילוץ חשבוניות (OCR)	תלוי במכסת השימוש מול ספק ה-AI החיצוני — ניתן להגדיל בהתאם לתוכנית מסחרית
אחסון תמונות	מתרחב אוטומטית; מדיניות המחיקה השוטפת (עם קבלת החלטה) שומרת על נפח מתון גם בהיקף גדול

גדילה משמעותית מעבר לכך: קפיצה להיקף ארצי גדול (מאות קניונים במקביל, עשרות אלפי הרשמות ביום) היא ריאלית עם התשתית הקיימת, אך מומלץ להקדים אותה בבדיקות עומס ייעודיות ובהתאמת תוכנית השימוש מול ספקי ה-AI וה-SMS החיצוניים, כדי לוודא שמכסות השימוש שלהם תואמות את קצב הצמיחה.

08 · אמינות והמשכיות

איך נשמרת יציבות השירות

אירוח מנוהל

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

פריסה מבוקרת

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

פעולות אטומיות

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

בידוד תקלות

תקלה בשירות חיצוני (למשל ספק ה-AI) מוצגת כהודעה ברורה ואינה משביתה את שאר המערכת.

09 · כיווני המשך

מה מתוכנן להתפתח

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

איך המערכת בנויהמאחורי הקלעים.