פיתוח לנדינג NFT מינט: היכן זה נשבר תחת עומס
שיא המכירה הוא הרגע שבו העומס על דף המינט מפסיק להיות תצוגתי. אלפי סשנים לוחצים בו-זמנית על הכפתור, כל אחד פותח סקר סטטוס של עסקה, ואם הבקשות הולכות ישירות לצומת הרשת, התשובות מגיעות בעיכוב של עשרות שניות. המשתמש רואה „מאשרים” נצחי, חוזר על הפעולה ועוזב.
נקודת הכשל השנייה — אובדן בקשות בשיא. כשההיצע מוגבל, כולם תובעים את אותו מלאי שנותר, ובלי תור בשרת הבקשות נכנסות לכתיבה מתחרה: העסקה נדחית ברמת הרשת, והאדם בטוח שהמינט לא עבר וסוגר את הדף.
אישורים תקועים הם תוצאה של כך שהסטטוס חי רק בדפדפן. ניתוק קשר, רענון או החלפת מכשיר, והמשתמש לא מבין אם הטוקן שלו שולם. הוא שולח מינט שני, מקבל קונפליקט לפי הכתובת וכותב לתמיכה במקום לקנות עוד.
יציבות דף המינט נשענת לא על הממשק, אלא על איך בנוי מסלול הבקשה: תור לכתיבה, ניסיונות חוזרים אידמפוטנטיים, שחזור סטטוס לפי כתובת הארנק, פריקת בדיקות מהצומת לשכבת מצבים נפרדת. הרצת עומס לא מאשרת דבר אם היא לא משחזרת כניסה בו-זמנית ותחרות על המלאי.
להלן נפרק איך זה נסגר בפיתוח לנדינג NFT מינט — מתרשים התור ועד התנהגות הממשק בעומס שיא של מכירה.
מה נותן לנדינג יציב: תפוקה ותורים
תחילת המכירה היא אלפי בקשות בו-זמנית בשנייה אחת, וצוואר הבקבוק מתגלה לא ברשת אלא בלנדינג עצמו: הממשק ממתין לתשובה, המשתמש שולח את הטופס שוב ולא מבין אם בקשתו עברה. המשימה היא לשמור על שיעור בקשות מוצלחות בשיא ולא לאבד את האמון של אלה שהגיעו ראשונים.
את הבסיס מחזיק תור בקשות עם סדר הוגן והגבלת קצב בפרימטר. הבקשה מקבלת מספר ואישור מיד, וחתימת העסקה עוברת בשירות נפרד עם תפוקה אחידה — תחת עומס זמן התגובה נשאר בגבולות שבהם האדם לא מתחיל לרענן את הדף ידנית.
בנפרד אנחנו סוגרים סוג כשלים שעולה הכי הרבה מבחינת מוניטין: חיובים כפולים. כל בקשה נושאת מפתח שנוצר בצד המשתמש, לכן בקשה חוזרת בעת ניתוק קשר מזוהה כאותה בקשה — היא לא יוצרת פעולה שנייה, אלא מחזירה את הסטטוס של הראשונה.
שירותים חיצוניים מכשלים: הצומת עונה לאט יותר, הארנק מחזיר שגיאה, שירות התשלום לא זמין. למקרה כזה הוגדרו זמני המתנה מקסימליים, ניסיון חוזר עם הגבלה וסטטוס ברור למשתמש — הבקשה לא נעלמת, אלא ממתינה לתורה. Cloudflare בפרימטר מפיג את הפרץ לפני שהוא מגיע לאפליקציה, לכן התור מתפנה ולא נחנק.
בתוצאה — התנהגות צפויה בשיא: שיעור יציב של בקשות מוצלחות, זמן תגובה אחיד ויומן פעולות נקי בלי חיובים כפולים.
השוואת מצבי השקה: רשימת גישה, מנות, מכירה פתוחה
מצב ההשקה קובע מי ומתי יכול לקרוא למינט ולפי איזה סימן החוזה בודק את הזכות. מכאן מתפצלים פרופילי העומס: רשימת גישה נותנת שיא קצר אחד מארנקים מוכנים, מנות — כמה גלים מבוקרים, מכירה פתוחה — זרם ארוך שאליו נכנסים גם בוטים.
את בדיקת הזכות עצמה (כתובת ברשימה, חתימה, חברות בעץ) מבצע החוזה, הלנדינג רק משקף את התוצאה שלה, לכן את המצב מקבעים לפני הפרסום.
הבחירה ביניהם היא פשרה בין כיסוי לבין צפיות העומס:
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מכירה לפי רשימת גישה | גרעין הפרויקט וקהל נאמן, נדרשת הגנה מבוטים | הרשימה נאספת מראש; לאחר פרסום ה-hash השורשי לא ניתן לערוך; חלק מהכתובות נפסלות לפי זכויות |
| מנות וגלים | חימום הדרגתי, תנאים שונים לפי שכבות, החלקת השיא | גבולות החלונות ומעברים בין גלים צריכים להיות אידמפוטנטיים; כשל במפגש פותח את הגל הבא לפני הזמן |
| מכירה פתוחה | כיסוי מקסימלי, אין חסם לארנקים חדשים | תנועה ובוטים מגיעים בו-זמנית; נדרשים מגבלה לארנק והגנה מקריאות המוניות |
| רשימת גישה → פתוחה | תרחיש ההשקה המרכזי: קודם שלנו, אחר כך השוק | נדרשת החלפת מצב בחוזה ועדכון סינכרוני של הממשק |
בלנדינג המצב קובע שלושה דברים: מה הארנק רואה לפני חיבור, אילו בדיקות עוברות לפני חתימת העסקה ואיך הממשק עובר בין מצבים. בדיקה מוקדמת בצד הלקוח חוסכת לאדם עסקה שנדחתה, אבל את הזכות מאשר החוזה — הממשק לא צריך להבטיח את מה שאין בו.
שלבי העבודה: אבחון עומס, תרשים, הגדרה, בדיקה, מסירה
סדר העבודה זהה גם למינט של 10 אלף ארנקים וגם לסדרת דרופים. קודם מודדים, אחר כך מתכננים ורק אחר כך כותבים קוד — אחרת צוואר הבקבוק מתגלה ברגע פתיחת המכירות, כשכבר אין מה לתקן, והרשת כבר עמוסה.
- אבחון עומס. אנחנו בודקים את הפרונט הנוכחי, סטטיסטיקות של דרופים קודמים, התנהגות של צמתי רשת וארנקים. מחשבים את השיא: כמה חתימות מגיעות בדקה הראשונה.
- תרשים גיבוי. קובעים היכן חיים חתימת העסקאות, מעקב nonce וסטטוס המינט, ומה יקרה בכשל של צומת או אזור. לכל רכיב מקצים מסלול גיבוי.
- הגדרת תורים. שמים תור לפני שליחת העסקאות, מגבילים קצב לפי ארנק וכתובת, מחברים Cloudflare בכניסה — בוטים מסוננים לפני שהם מגיעים לצומת.
- הרכבת הלנדינג. הפרונט עובד עם הארנק, מציג סטטוס, מפיג לחיצות חוזרות ושומר מצב ברענון, כדי שהמשתמש לא יאבד את מקומו בתור.
- בדיקות עומס. מריצים פרופיל של שיא צפוי ופרופיל עם מרווח. בודקים זמן תגובה, שיעור מינטים מוצלחים והתנהגות המערכת בכשל של שירות אחד.
- מסירה לתמיכה. מוסרים תרשים, קונפיגורציות, דשבורדים ונוהל דגרדציה: מה לעשות אם ספק הצמתים מאט או הרשת נפלה.
מה נשאר בפרויקט אחרי המסירה: קונפיגורציות ונוהלים
מסירה היא לא ארכיון עם קוד ולא גישה לריפו שמוסברת במילים. הפרויקט נמסר כערכה שלמה, שלפיה הצוות שלכם יוכל לפרוס מחדש את הסביבה, לבצע בדיקה ולהכניס שינויים בלעדינו. להלן מה בדיוק נשאר בידיים אחרי סגירת העבודות.
- קונפיגורציות של סביבת בדיקה וסביבת עבודה בריפו: משתנים, סודות במאגר מוגן, פרמטרים לחיבור לרשת ולצמתים — עם הסבר מה אחראי למה.
- תרשים תשתית: איך קשורים מאזן העומס, השירותים, מסד הנתונים, התורים והצמתים החיצוניים, היכן נקודות הכשל ובאיזה סדר מתבצעת החלפה בעת דגרדציה.
- מדיניות גישה: תפקידים ותחומי הרשאות — מי קורא, משנה, מוציא כספים; כללי רוטציה של מפתחות חתימה וארנקים, תיעוד פעולות.
- תיעוד ונוהלים: תיאור מודולים וחוזים, תרשים נתונים, רשימת תלויות חיצוניות וסדר העדכון שלהן.
- הוראות לצוות: הפעלה ועצירה של הסביבה, בדיקות לפני שחרור, חזרה לגרסה קודמת, שחזור מגיבוי.
- נוהל תורנות: מה נחשב אירוע חירום, זמן תגובה, למי נשלחת התראה ואיך מתועדת חקירה אחרי תקרית.
- תרחישי קבלה: סט בדיקות שלפיהן אתם בעצמכם מאשרים את תקינות המינט אחרי המסירה, בלי השתתפותנו.
כל סעיף נבדק בקבלה: אם אי אפשר לשחזר את הפרק לפי המסמך, הוא נחשב לא סגור.
מקרה בוחן: מכירת שיא בלי תור ובלי כשלים
המכירה הגדולה הראשונה של הקולקציה הייתה על 10,000 כתובות, ולפני ההתחלה הרצת עומס הראתה: בשיא הביקוש הבקאנד עונה 6–9 שניות, חלק מהתשלומים עוברים לחריגת זמן המתנה, ותור הבקשות גדל מהר יותר מקצב הטיפול בו.
לפי תוצאות עשר הדקות הראשונות, שיעור הבקשות המוצלחות ירד ל-61%, ומחצית המשתתפים כתבו לתמיכה — בעיקר כדי לברר אם התשלום עבר ואם לא חויבו פעמיים.
מה שינו
קליטת הבקשות ואישור התשלום הופרדו: הבקשה נרשמת מיד בתור עם מפתח לפי כתובת הארנק — לחיצה חוזרת לא יוצרת רשומה שנייה — ובדיקת העסקה עוברת למעבד נפרד עם ניסיונות חוזרים. מצב המכירה מוגש מהמטמון, שמתעדכן לפי אירועי הרשת, לכן הדף לא מחשב מחדש את המונה בכל פתיחה. תאימות לארנקים המוניים כמו MetaMask והתנהגות בחיבור סלולרי איטי נבדקו לפני ההתחלה.
מה התוצאה
על אותו פרופיל עומס כמו בהרצה הראשונה: שיעור הבקשות המוצלחות — 99.3%, זמן תגובה באחוזון ה-95 — 0.4 שניות במקום 6–9. פניות לתמיכה בהתחלה ירדו ממחצית המשתתפים ל-2.8% ונגעו לממשק, לא לתשלומים. בנפרד השארנו בדיקה לכניסה חוזרת: במהלך המכירה לא נרשמו חיובים כפולים.
במה שונה מכירה לפי רשימת גישה מהשקה ציבורית?
מכירה לפי רשימת גישה היא מרשם סגור: הכתובת נרשמה מראש, הלנדינג בודק את חתימת הארנק ואת הזכות לקנות לפני פתיחת הטופס.
פרופיל העומס כאן צפוי — הוא תואם למספר הרשומות במרשם, והשיא נמתח על חלון המינט, לכן צוואר הבקבוק הוא בדרך כלל לא השרת, אלא נכונות בדיקת הזכויות והגנת המרשם עצמו מפני דליפה.
השקה ציבורית משנה את פרופיל העומס באופן קיצוני: בשניות הראשונות מגיעים עשרות אלפי בקשות מקבילות מכתובות לא מוכרות, והלנדינג צריך לעמוד בפרץ בלי לאבד אף רכישה מאושרת.
כאן מתכננים מראש תור, מגבלה לכתובת ועיבוד אידמפוטנטי של ניסיונות חוזרים — אחרת חלק מהקונים יראו שגיאה כשהעסקה למעשה עברה.
גם הסיכונים של קניות אוטומטיות בשני התרחישים שונים. ברשימת גישה סקריפטים מנסים להגיע למרשם ולמתן הזכויות, במכירה פתוחה — לעקוף את האחרים במהירות שליחת העסקה. לכן ההגנה נבנית על חתימה, הצמדה לכתובת ובדיקה בצד השרת, ולא רק על מגבלות ממשק שאפשר לעקוף בדקות.
בהיקף העבודה מכירה פתוחה דורשת יותר: חישוב עומס שיא, חזרה על הפרץ, נראות ותוכנית דגרדציה בכשל של צומת חיצוני. רשימת גישה קרובה יותר לניהול מרשם ולבדיקת זכויות, אבל דורשת לא פחות תשומת לב לאיך זכויות ניתנות, נשללות וחיות בין סבבים.
ספקות הנדסיים: מגבלות, ניסיונות חוזרים, שחזור
שיא המינט נתקל לא בחוזה, אלא בתלויות חיצוניות: צמתי רשת, שער תשלום, שירות מטא-דאטה. לכל אחד יש מגבלת בקשות משלו, ובגל של סשנים בו-זמניים הממשק מתחיל לקבל דחיות — לא כי משהו נשבר, אלא כי איש לא ניהל תורים. להלן הספקות שנשמעים הכי часто בדיון, והתשובות שלנו לגופן.
שירות חיצוני נתקל במגבלת בקשות — המינט ייעצר?
לא, רק מסלול עיבוד אחד ייעצר. אנחנו מפרידים קריאה וכתיבה: מצב המינט והמטא-דאטה מוגשים מהמטמון, ולשירות החיצוני יוצא מינימום קריאות. הבקשות עוברות דרך תור עם הגבלת קצב ועדיפויות — אישור תשלום תמיד לפני טעינת סטטיסטיקות.
האם ניסיונות חוזרים לא ייצרו עסקה שנייה?
לא, אם הכתיבה מתבצעת לפי מפתח אידמפוטנטיות. הבקשה מקבלת מזהה לפני השליחה, וניסיון חוזר בהיעדר תשובה שולח את אותו מזהה, ולא פעולה חדשה. המרווח בין הניסיונות גדל עם פיזור, לכן גל ניסיונות חוזרים לא מכה בשירות בו-זמנית.
מה לעשות עם בקשות תקועות?
לכל בקשה יש מצב וזמן שינוי אחרון. מעבד רקע מוצא את אלה שתלויות יותר מהסף, משווה למצב בפועל ברשת, או מביא לתוצאה או מסמן כמבוטלות. המשתמש רואה סטטוס מעודכן, ולא אינדיקטור אינסופי.
איך הממשק שורד דגרדציה?
הוא נשאר פעיל: מנותקים בלוקים משניים — פיד, מונים, תצוגה מקדימה של הקולקציה — אבל כפתור המינט והסטטוס עובדים. אם צומת הרשת הראשי לא עונה, התנועה עוברת לצמתי גיבוי, ובמקום שגיאת דמה מוצג מצב אמיתי.
נדבר על המשימה: פרופיל עומס ותוכנית השקה
פרופיל העומס הוא מה שממנו מתחילים את ההערכה והתוכנית: בלי מספרים על ביקוש שיא כל ארכיטקטורה תהיה ניחוש. תארו את המשימה בהודעה אחת — מכניקת המינט, הרשת, הקהל הצפוי — וצרפו נתונים שבדרך כלל יש לשיווק ולצוות שהכין את הקולקציה. זה מספיק כדי לחזור עם חישוב תפוקה, תרשים גיבוי וזמני עבודה לפי שלבים.
מה כדאי לשלוח מראש כדי שההערכה תהיה עניינית:
- תרחיש שיא: כמה ארנקים ילחצו על המינט בו-זמנית בדקה הראשונה וכמה עסקאות בשנייה צריך להחזיק;
- מכניקת גישה: השקה פתוחה, רשימת מורשים, אישורים חתומים, מגבלות לכתובת;
- רשת ותנאים: היכן מתבצע המינט, במה משלמים, צריך העברה בין רשתות;
- היקף הנפקה ושלבים: מספר הטוקנים הכולל, מנות, גלים לפי זמן, מכירה בדקה אחת או ביממה;
- מקורות תנועה: פלטפורמות הכרזה, מספר ביקורים צפוי, אזורים — מזה תלויים מטמון והגנה מבקשות אוטומטיות;
- מגבלות תשתית: היכן מאוחסן הפרונט, יש גישה לצומת משלכם, דומיינים, דרישות ליומני פעולות;
- תאריך השקה יעד והצמדות קשיחות להכרזות שאין לבטל.
בתמורה אתם מקבלים הערכה ותוכנית: חישוב עומס עם מרווח, תרשים תור וניסיונות חוזרים בכשלים, סדר הכנה להשקה — הרצות בדיקה בסביבת בדיקות עם סימולציה של שיא, בדיקת ארנקים וחתימות, חזרה עם קבוצה מוגבלת.
זמני העבודה מחולקים לפי שלבים, בנפרד מקבעים את הרגע שאחריו כבר מסוכן לשנות את מכניקת המינט, ומתארים חזרה לאחור אם יהיה צריך לעצור את ההשקה.