שיעורים על הסכמה בקנה מידה עם אדריכלות ללא שרתים

הסכמה בקנה מידה היא ההבדל בין האמון בתיעוד הפיננסי שלך לבלות את הלילות רודף אי-התאמה בין צדדים מרובים.ב- Lead Bank, אנו בונים את התשתית אשר אוספת, מעבדת ומסייעת נתונים עבור תוכניות כרטיסי אשראי ותשלומים כדי לתמוך במדויקנות, בדיקת ואחריות לעמידה. הסכמה בודקת עקביות ברחבי היסוד הבנקאי, קבצי הרשת של כרטיסיות, דוחות מעבדים שפורסמו ונתוני תוכנית פינטטק, ומכיוון שהיא מכסה מספר צדדים, זרימת העבודה מורכבת מכמה רגלים, ובלתי תואם אחד יכול להוביל לחקירה יקרות ולהגדיל את הסיכון להתאימות. הפוסט הזה עובר דרך האדריכלות ללא שרת של AWS שנוצרה עבור הסכמה מרובה צדדים, שני מכשולים הייצור שנפגשו קודם (גבולות עיבוד קבצים ו- Amazon DynamoDB לכתוב נקודות חמות), ואת הדפוסים ששימשנו כדי להקל עליהם. I. הקשר והגבלות הטכניות של הסכמה בקנה מידה ב- Banking-as-a-Service (BaaS) תוכניות כרטיסיות, FinTechs בדרך כלל פועלים באמצעות מספר זיהוי בנק (BIN) ספונסר, בנק המפיץ מאובטח על ידי FDIC אשר מחזיק ברשת כרטיס רישיון והוא אחראי על חיוב ופיקוח על התוכנית. רכישת כרטיס מתחילה עם בקשת אישור, בדרך כלל מתבצעת בהודעה ISO 8583, תקן משותף להודעות עסקאות כרטיס בזמן אמת המוחלפות בין רכבים לבין מפיצים באמצעות רשתות כרטיס. חישוב הכספים בפועל מתרחש למחרת, כאשר הרשת מפצה את קבצי חישוב הרשת לכל המשתתפים. הפרדה זו בין אישור בזמן אמת לבין הסדר המשלוח היא אחת הסיבות העיקריות שההסכמה מבוססת על קבצים וקריטית מבחינה תפעולית. הסכמה היא שליטה שמבצעת אימות בין רשומות פנימיות ומקורות חיצוניים של אמת, כולל הליבה הבנקאית, רשת הכרטיסים או קבצי מעבד, ונתוני תוכניות פינטטק. בפוסט זה, הישות היא הצרכן הסופי של תוכנית פינטק. חשבון הוא אובייקט המכיל הרבה מטא-נתונים על היחסים של הישות עם תוכנית פינטק. איזון הוא אובייקט המכיל ערך הנקרא במטבעות שונים. עסקה היא אובייקט המתאר אירוע פיננסי, כגון רכישה, תשלום, או החזר שמשנה את הערך של איזון נתון. כרטיס הוא אחד המכשירים שיכולים לשמש לבצע עסקה ולשנות את איזון. בפועל, הסכמה מחולקת לארבעה תנועות עבודה חוזרות, כל אחת עם מגבלות טכניות שונות: בדוק את העסקאות המייצגות את המשקל. הוכחה לכך שהסכום של רווחים ברמה של הלקוח שווה לרווחת ה-Omnibus For-Benefit-Of (FBO) של הבנק. תואם פעילות כרטיס שפורסמה לקבצי חישוב רשת או מעבד למרות נפח, משתנות פורמט וזיהוי לא תואם או זמן בין הצדדים. לאמת את זהותך, מצב כרטיסך ונתוני ההרשמה לחשבון שיכולים לבטל את ההתאמה הפיננסית אם היא לא תקינה או לא תואמת. למרות שנושאי עבודה רבים פועלים באמצעות ממשק התוכנה של היישום (API), ההסכמה עדיין נשלטת על ידי קבצים של סוף היום, כי הם מספקים צילומי רגע שאפשר לבדוק ותומכים בהעברה מחדש דטרמיסטית. משלוח קובץ לא מושלם ותחזורים: קבצים מגיעים באיחור, לא בסדר, כפופים או מתוקנים, ולכן הצינור חייב להיות יעיל ובטוח להפעיל מחדש. מזהים אינם מצוידים בצורה נקיה: אותה עסקה יכולה לשאת מזהים שונים בין הצדדים, ולכן התאמה דורשת לעתים קרובות מפתחות מורכבים ולוגיקה של korrelation. סמנטיקה של הסתגלות כבדה: החזרים, מחלוקות, תשלומים ותיקונים משנים את הכללים המתאימים עם הזמן ולהגדיל את הרחבת הכתיבה. שתי בעיות הייצור מופיעות בשלב מוקדם: עיבוד קבצים ארוך עשוי לחצות גבולות חישוב קצרים, ואילו נפח כתיבה גבוה יכול ליצור דפוסי גישה לא שווים ומחלקות חמות באחסון הנתונים של ההסכמה. במאמר זה, אנו מתמקדים באתגרים הטכניים של הסכמה פיננסית, במיוחד בדיקות איזון ודירוג הסדרת הרשת, וכיצד תכננו צינור ללא שרת של AWS סביב המגבלות הללו. ארכיטקטורה ללא שרתים: פירוק ותזמורת בהתחשב בהגבלות האלה, התחייבנו לארכיטקטורה ללא שרת ראשון כדי למזער את ההתקנה, למקסם את הזמינות ולתמוך בקנה מידה אוטומטי.הגישה הזו מאפשרת לצוות הקטן שלנו לחזור במהירות ולהתמקד במאמצים הנדסיים שלנו על לוגיקה עסקית פיננסית מורכבת במקום תחזוקה וטבילה של תשתית, ובכך להפחית באופן משמעותי את פרופיל עלויות התפתחותינו ועלויות התשתית. ו כדי לשמור על המאמר פשוט וממוקד, נתרכז רק בקבצים פיננסיים. Amazon Simple Storage Service (Amazon S3), Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon DynamoDB, AWS Lambda, Amazon Elastic Container Service (Amazon ECS), AWS Step Functions A. Ingestion and Event Routing (Amazon S3 ו-Amazon EventBridge) התהליך מתחיל כאשר אחד הקבצים (Transaction, Balance, or Network Settlement) נופל לתוך תיקיה של Secure File Transfer Protocol (SFTP) שמסונכרנת עם S3 buckets. In our design, we routed S3 object-created events through EventBridge instead of using direct S3 notifications.This made the ingestion path easier to evolve because producers and consumers remained loosely coupled.It also gave us a consistent place to apply filtering and routing rules across multiple event sources. עקבו אחרי Amazon SQS (Amazon SQS) בעיצוב שלנו, כללי EventBridge מכוונים לקו סטנדרטי של SQS כדי לספק חיתוך קבוע ולנתק את צריכת המים מהעיבוד. אם שלושה קבצים מסיביים מגיעים בו זמנית, המצורף סופג את העומס, עוזר להבטיח כי השירותים המחשבים שלנו במעבר למשוך הודעות בקצב יציב, בר-קיימא במקום להיות מכוסה. עמידות: ההודעות נמשכות ב- SQS עד שהם מעובדים בהצלחה, ומבטיחות לפחות משלוח אחד. Dead Letter Queue (DLQ): כל שורה של SQS מוגדרת עם DLQ. אם Lambda לעיבוד נכשל שוב ושוב (למשל, עולה על המספר המקסימלי של 5), ההודעה מועברת ל-DLQ לבדיקה ידנית, כך שאין עסקה אבודה בשקט. C. Compute Layer (AWS Lambda ו- Amazon ECS) תשתית המחשוב שלנו מחולקת אסטרטגית על מנת לאופטימיזציה של עלויות ותקופות: AWS Lambda: מתמודד עם עבודות קלות, שבורות ואורקסטרציה, כגון בדיקה של הודעות ומניעת מפת מקבילה של Step Function. Lambda מציעה התחלות קרות מהירות מאוד ועלויות נמוכות עבור משימות אפמינליות המובטחות להשלים תוך 15 דקות. AWS ECS Fargate: מוגבל לתפקידי הסכמה הדורשים זיכרון גבוה או מעבר ל-Lambda timeout של 15 דקות (קונפליקט נפוץ, כפי שמפורט בסעיף III). פונקציות שלב של AWS (AWS Step Functions) הסכמה היא זרימת עבודה ארוכה, לעתים קרובות מרובות ימים, ולכן AWS Step Functions מתאימה היטב לאורקסטרציה ללא שרת כדי לתאם את צעדי החישוב הפרטיים. הסיבות לבחירה הזאת מושרשות בצורך האדריכלי: מצב מנוהל ותקיימות: הסכמה כוללת עשרות שלבים רצופים ושלבים מקבילים (החלקה, נורמליזציה, תואמות, אוסף). פונקציות של שלב מנוהלות באופן טבעי את המצב בין שלבים כאשר שירות מתמשך נכשל (לדוגמה, שגיאה של Lambda). מקבילות גדולות באמצעות מצב מפה: בהתאם למקרה השימוש שלנו, ביצענו משימות מסוימות במקביל באמצעות מצב מקבילה, וכמו כן, כאשר רצינו לחזור על אותה משימה עם כניסה שונה, השתמשנו במצב מפה Debugging ו- Auditability: עבור תאימות ופעולות, היכולת לחזות את כל זרימת העבודה היא בעלת ערך. Step Functions מספקת תצוגה גרפית של כל שלב, כולל הכניסות, היציאות והסיבות לכישלון. E. שכבת ההתמדה (Amazon DynamoDB) בחרנו את DynamoDB כבסיס הנתונים העיקרי שלנו לאחסון רשומות עסקאות ואיזון בלתי משתנים בשל המאפיינים החיוניים שלה עבור תוכנית כרטיסים מסיבית: נפח גבוה, עיכוב נמוך: DynamoDB מיועד לעיכוב צפוי של מיליש"ט אחד בגודל גבוה, אשר נדרש עבור זרימת עבודה פיננסית. ללא שרת ומנוהל: על ידי ניצול טבעו המנוהל לחלוטין, הסירנו את הטרחה של אספקת, תיקון ופירוק של מסד נתונים יחסיים מסורתי (MySQL / Postgres), המאפשר לנו להתמקד לחלוטין באתגרים ברמת היישום, כגון עיצוב מפתח מחלקה. DynamoDB Streams הם חיוניים, ומספקים זרם כמעט בזמן אמת של שינויים המפעילים את התאימות, האנליטיקה, ומערכות אחסון נתונים (Snowflake). הגרסה הפשוטה שלנו של זרימי כרטיסי החיוב שלנו נראו ככה. במחצית העליונה, המעבד המוציא את קבצי הרשת שמסונכרים ל-S3. חוק EventBridge מקשיב לאירועים חדשים ב-S3 ומעביר אותם לקו ה-SQS המוציא. במחצית התחתונה, זרימת ה-fintech מתחילה כאשר שותף ה-fintech מוריד את קבצי ה-transaction ו-balance.This triggers an event routed through the SQS queue to the Initiator Lambda, which then starts a separate Step Function that validates and reconciles the files against the network settlement data.This process is called network reconciliation. בצד הימני, יש לנו הסכמה FBO, אשר מתאים את קובץ האיזון של Fintech עם הסכום שהוסכם בחשבון FBO, כדי לתמוך מדויק של סוף סוף ברחבי רשת, Fintech, ורישומים בנקאיים. הקרב המשמעותי: להתגבר על גבולות ללא שרתים ארכיטקטורה זו עבדה היטב בהתחלה, אבל ככל שהקצב שלנו גדל, פגענו בשני קשיים קריטיים: משך החישוב והפרטיזציה של מסדי נתונים, אשר הכריחו אותנו לפתח את הגישה שלנו. A. אופטימיזציה של מחשב: ההעברה Lambda-to-ECS בעוד שהחלוקת קבצים עזרה, לוגיקה מורכבת של הסכמה בין חתיכות גדולות (לדוגמה, 20,000 רשומות בקובץ רחב-עמודה, רחב קבוע) עדיין מדי פעם עברה את החלון הזה. הפתרון שלנו לא היה עיצוב מחדש, אלא שינוי ארכיטקטוני פשוט: בסיס קוד מאוחסן: שמרנו על עובד פירוק ליבה יחיד, יישום מאוחסן שנכתב ב-Go, אשר עבד על פירוק קבצים ועיבוד. ביצוע דינמי: הפעלנו את תמונת המכולת הזו הן ב-Lambda (לביצוע מהיר ואפמינלי) והן ב-ECS Fargate (לביצועים אינטנסיביים לזיכרון). בחירת פונקציה של שלב: פונקציה של שלב משתמשת במצב של בחירה בתחילת התהליך. אם גודל הקובץ נמצא מתחת לגבול מסוים (למשל, 1GB), היא מכוונת לפונקציה של Amazon Lambda. גישה זו נתנה לנו איזון מעשי: היעילות והמהירות של Lambda עבור 90% של קבצים קטנים יותר, ואת כותרת החישוב של Fargate עבור 10% של עסקאות גדולות, איטיות לעיבוד וקבצי איזון. B. Mastering DynamoDB for High-Throughput Writes DynamoDB הוא בחירה מצוינת עבור מסד נתונים שיש לו דרישות נפח גבוה, איחור נמוך לאחסון עסקאות. עם זאת, גמישותו נקבעה על הפצה I/O באופן שווה בין הפריטים. התנגשות מתרחשת כאשר מפתח מחלקה יחיד עולה על הגבול שלו (בדרך כלל 1,000 יחידות כתיבה (WCU) או 3,000 יחידות קריאה (RCU) לשנייה). היה לנו מפתח מחלקה ProgramID#FileDate (למשל, PROGX#20250101) עיצוב זה נכשל כי כל העסקאות עבור תוכנית מסיבית ביום אחד פגעו מעבר למגבלת ה- WCU והזריעה. מצא את כל העסקאות עבור תוכנית מסוימת בתאריך מסוים אותו חלוקת שיעור Backpressure של Global Secondary Index (GSI): בתחילה ניסינו לפתור את זה על ידי העברת המפתח העיקרי עם קדנליות גבוהה ל- GSI ולחקור את GSI במקום. עם זאת, זה לא נתן שום הקלה. מכיוון שה- GSI מקבל את זרימת הנתונים שלו מהטבלה העיקרית, אם חלוקה של הטבלה העיקרית כבר מוחזקת, זרימת הקו של GSI תתמודד עם לחץ אחורי GSI, המגביל בסופו של דבר את כניסת הכתיבה של הטבלה כולה. עיצוב מפתח אופטימי: Partition Key Sharding: התיקון שלנו היה להציג כתיבה sharding עבור הלקוחות הגבוהים ביותר שלנו: PK Sharding: הוספנו מספר shard חישוב למפתח המקטע: ProgramID#FileDate#ShardN. Sharding Logic: השתמשנו באלגוריתם hashing קל (למשל, modulo) על TransactionID כדי להקצות אותו ל-shard (למשל, TransactionID % 10 תוצאות במספר shard בין 0 ל- 9). התוצאה: זה הפצה את עומס הכתיבה על עשר מקטעים פיזיים במקום אחד, באופן מיידי להקל על הבעיה של מקטעים חמים ומאפשר לנו לצרוך נתונים בקצב גבוה פי 10 יותר. שיעורים אפשריים לומדים סעיף זה מסכם דפוסים שאתה יכול ליישם צינורות הסכמה משלך, עם דוגמאות מהיישום שלנו. שיעורי עיצוב מערכות הנה שלושה שיעורי עיצוב מערכות שאתה יכול ליישם כאשר אתה בונה צינור פירוק שיש לטפל מחדש, כניסות לא מושלמות, ומערכות חיצוניות מרובות: Make retries safe by default (idempotency is the baseline): In an event-driven pipeline, retries are expected, so you should design each step to be safely repeatable. For our use case, we had to pass an idempotency key (for example, a TransactionID or MessageID) through the workflow and use it to guard every side-effecting operation. In practice, that means: Workflow steps: each state transition is protected with conditional writes (for example, in DynamoDB) so the same message cannot advance or mutate state twice. Core banking transactions: postings, transfers, and ledger-affecting actions are executed with explicit dedupe semantics (same idempotency key → same outcome), so a retry results in a no-op or a deterministic “already processed” response rather than a duplicate movement of funds. Webhooks and outbound notifications: These are delivered at least once, so each message includes a stable, recipient-facing idempotency key (event ID) and we maintain an internal delivery ledger (attempts, acknowledgements, and final state). Recipients can safely dedupe replays, and our retries won’t trigger duplicate downstream actions. Always Use a Dead Letter Queue (DLQ): and a redrive policy so that malformed messages are quarantined instead of endlessly retrying and clogging the queue. Configure a SQS DLQ Do not let a service be the only source of truth for its own correctness.: Reconciliation is cross-system by definition, so build checks that validate invariants from the outside. For example, comparing transactions sent by the program against the network and their FBO was very important. הגדרת SQS DLQ B. שיעורים של מצוינות מבצעית שיעורי הפעולה האלה מתייחסים להפחית את הזמן לזיהוי ולתקן על ידי הפוך את הכישלונות לראויים, אפקטיביים וקלים לחקור עבור הצוות שלך ואת השותפים שלך. התמקדות בתצפיות פנימיות: מצאנו כי תרבות של תצפיות עדיפה על דיבוג קבוע. התמקדותנו עברה מלהגיב לשגיאות כדי למנוע אותן, אשר דורש משמעת תפעולית ברחבי הלוח. המפתח לכך היה זיהוי מוקדם של נקודות החום שלנו (הגדרת אזהרות קפדניות ומגבלות עבור מדדים כגון עומק שורה של SQS ו- DynamoDB) על ידי הגדרת מטרות רמת השירות הנדרשות (SLO). התמקדות בתצפית חיצונית: עליך להפוך את כישלונות ההסכמה לפעול עבור הלקוחות על ידי החזרת הודעות שגיאה ברורות, שירות עצמי והנחיות. השקעה בכלים: בנה כלים לחקירה מוקדם כך שתוכל לעקוב אחר חוסר התאמה לקובץ המקור, לביצוע העיבוד, ולכתוב את התוצאה מבלי לחפור דרך יומנים. התמקדו במהירות כדי לקבל משוב: עליכם לאופטימיזציה עבור חבילות משוב מהירות.ללא שרתים אפשרות להפעיל את ההפעלה המהירה ועלויות התפתחות נמוכות.אחרי החודש הראשון של הפעלת מערכת ההסכמה המבוססת על אירועים זו, המחיר הכולל של מחשב הענן שלנו היה קטן יותר מחשבוני הארוחה של הצוות שלנו.ארכיטקטורה זו אפשרה לצוות הקטן שלנו לחזור במהירות ולהתמקד לגמרי בהיגיון הפיננסי המורכב, ולא בהשפעה. עיצוב ממשק: File vs. API טעות נפוצה הייתה ההגדרה כברירת מחדל לממשקים המבוססים על קבצים כאשר API היה מתאים יותר לתהליך העסקי. השתמש בממשק הנכון עבור הבעיה: אין כאן תשובה נכונה; אתה צריך לחשוב דרך מה הפריצה הנכונה היא כדי לפתור את הבעיה. השתמשנו בקבצים רק עבור פעולות סדרה בפועל שבו צילומי סוף היום הם הדרישה (למשל, הסדר רשת). לאחר מכן השתמשנו APIs עבור כל דבר אחר, במיוחד כאשר משוב בזמן אמת או העברות נתונים קטנות ודיסקרטיות נדרשות. נאלצנו לכתוב מחדש מספר ממשקים פנימיים מ- uploads מבוססי קבצים ל- HTTP APIs כי העלילה המבצעת של מעקב, עיבוד, ו- debugging של קבצים קטנים רבים הוכח להיות הרבה יותר מורכב מאשר שיחת API פשוטה. התייחסו לסכמי קבצים כמו לסכמי גירסה: עליכם להתייחס לסכמי קבצים כאל הסכמי גירסה, מכיוון ששינויים קטנים יכולים לשבור את הבדיקה ולהפריע בשקט לתוצאות ההסכמה. מסקנה בניית מערכת ההסכמה המשתלבת ב- AWS היא פחות על בחירת רכיבים ללא שרתים, יותר על עיצוב לכישלון, לשחזור ולחקירות.בביצוע היישום שלנו, שירותים ללא שרתים של AWS סיפקו בסיס מוצק לאורקסטרציה ולמצב בר-קיימא.תוצאות הייצור תלויות בסופו של דבר בפרטים, במיוחד אידיפוטנציאל, עיצוב מפתח מחלקה, וסימנים תפעוליים שגרמו לכישלונות לזהות ולפתור במהירות.