บทเรียนเกี่ยวกับการประสานงานในระดับที่มีสถาปัตยกรรมที่ไม่มีเซิร์ฟเวอร์

การประสานงานในขนาดคือความแตกต่างระหว่างการไว้วางใจในเอกสารทางการเงินของคุณและใช้เวลากลางคืนในการติดตามข้อผิดพลาดระหว่างหลายบุคคล ที่ Lead Bank เราสร้างโครงสร้างพื้นฐานที่เก็บรวบรวมประมวลผลและประสานงานข้อมูลสําหรับโปรแกรมบัตรและเงินฝากเพื่อสนับสนุนความถูกต้องความสามารถในการตรวจสอบและภาระผูกพันในการปฏิบัติตาม Reconciliation ตรวจสอบความสม่ําเสมอทั่วแกนธนาคารไฟล์เครือข่ายบัตรรายงานการประมวลผลการส่งออกและข้อมูลโปรแกรม fintech เนื่องจากครอบคลุมหลายบุคคลกระบวนการทํางานมีหลายขาและไม่สอดคล้องกันเดียวสามารถกระตุ้นการตรวจสอบที่มีราคาแพงและเพิ่มความเสี่ยงในการปฏิบัติตามข้อกําหนด โพสต์นี้จะเดินผ่านสถาปัตยกรรม AWS serverless ที่เราสร้างขึ้นเพื่อให้ร่วมกันหลายบุคคลขีดข่วนการผลิตสองขีดข่วนที่เราพบครั้งแรก (ขีด จํากัด การประมวลผลไฟล์และ Amazon DynamoDB เขียนจุดร้อน) และรูปแบบที่เราใช้เพื่อบรรเทาพวกเขา มันถูกเขียนสําหรับวิศวกรซอฟต์แวร์และสถาปัตยกรรมที่ต้องการแผนผังทางปฏิบัติสําหรับการสร้างเครื่องยนต์ร่วมกันไร้เซิร์ฟเวอร์ I. ความขัดแย้งและข้อ จํากัด เทคนิคสําหรับความซื่อสัตย์ในขนาดใหญ่ ในโปรแกรมบัตร Banking-as-a-Service (BaaS) fintechs โดยปกติจะทํางานผ่านการสนับสนุนหมายเลขประจําตัวธนาคาร (BIN) ธนาคารผู้ออกเงินที่ได้รับการประกันโดย FDIC ซึ่งถือใบอนุญาตเครือข่ายบัตรและรับผิดชอบการชําระเงินและการดูแลโปรแกรม โปรแกรมมักจะเกี่ยวข้องกับบทบาทสี่บทบาท: เครือข่ายบัตร (สําหรับเส้นทางและกฎ) ธนาคารผู้ออก (ผู้ออกเงินตามกฎหมายและพันธมิตรการชําระเงิน) ผู้จัดการโปรแกรม fintech (ประสบการณ์ผู้ใช้สุดท้ายและการดําเนินงาน) และตัวประมวลผลผู้ออก (การอนุญาตในเวลาจริงและการดําเนินงานบัญชีบัตร) การซื้อบัตรเริ่มต้นด้วยคําขออนุญาต โดยปกติจะดําเนินการในข้อความ ISO 8583 เป็นมาตรฐานทั่วไปสําหรับข้อความการทําธุรกรรมบัตรแบบเรียลไทม์ที่แลกเปลี่ยนระหว่างผู้ซื้อและผู้ออกบัตรผ่านเครือข่ายบัตร เครือข่ายใช้ BIN ของบัตรเพื่อนําคําขอไปยังผู้ออกบัตรเพื่อให้มีการตัดสินใจในการอนุมัติหรือปฏิเสธ การอนุญาตไม่ได้ถ่ายโอนเงิน การชําระเงินเงินจริงเกิดขึ้นในวันถัดไปเมื่อเครือข่ายกระจายไฟล์การชําระเงินเครือข่ายไปยังผู้เข้าร่วมทั้งหมด การแยกระหว่างการรับอนุญาตแบบเรียลไทม์และการชําระเงินแบบพาร์ทิชันเป็นเหตุผลหลักที่ทําให้การจับคู่เป็นไฟล์และมีความสําคัญในการดําเนินงาน การประสานงานคือการควบคุมที่ตรวจสอบความสอดคล้องระหว่างบันทึกภายในและแหล่งที่มาของความจริงภายนอกรวมถึงหลักธนาคารเครือข่ายบัตรหรือไฟล์โปรเซสเซอร์และข้อมูลโปรแกรม fintech เนื่องจากระบบเหล่านี้แตกต่างกันในตัวระบุเวลาและการปรับความหมายการประสานงานเป็นส่วนประกอบหลายบุคคลและหลายขั้นตอน การไม่สอดคล้องครั้งเดียวสามารถกระตุ้นการตรวจสอบที่มีค่าใช้จ่ายและเพิ่มความเสี่ยงในการปฏิบัติตามข้อกําหนด ในโพสต์นี้ Entity เป็นผู้บริโภคสุดท้ายสําหรับโปรแกรม FinTech บัญชีเป็นวัตถุที่มีข้อมูลเมตาข้อมูลจํานวนมากเกี่ยวกับความสัมพันธ์ของ entities กับโปรแกรม FinTech Balance เป็นวัตถุที่มีมูลค่าในสกุลเงินต่าง ๆ การทําธุรกรรมเป็นวัตถุที่อธิบายเหตุการณ์ทางการเงินเช่นการซื้อการชําระเงินหรือการคืนเงินซึ่งเปลี่ยนมูลค่าของสกุลเงินที่กําหนด บัตรเป็นหนึ่งในเครื่องมือที่สามารถใช้ในการทําธุรกรรมและเปลี่ยนสกุลเงิน หลักธนาคารเป็นรายชื่อที่ถือเงินของโปรแกรม ในทางปฏิบัติการประสานงานแบ่งออกเป็นสี่กระบวนการทํางานที่ซ้ําซ้อน แต่ละกระบวนการมีข้อ จํากัด เทคนิคที่แตกต่างกัน: ตรวจสอบการทําธุรกรรมที่สร้างสมดุล แสดงให้เห็นว่าจํานวนของยอดคงเหลือระดับลูกค้าเท่ากับยอดคงเหลือ For-Benefit-Of (FBO) ของธนาคารหลัก การจับคู่กิจกรรมการ์ดที่โพสต์กับไฟล์การกําหนดค่าเครือข่ายหรือโปรเซสเซอร์แม้จะมีปริมาณการเปลี่ยนแปลงรูปแบบและตัวระบุหรือเวลาที่ไม่สอดคล้องกันระหว่างบุคคล ตรวจสอบข้อมูลการระบุตัวตนสถานะบัตรและข้อมูลอ้างอิงการอนุมัติบัญชีที่สามารถยกเลิกการจับคู่ทางการเงินหากไม่สอดคล้องหรือไม่สอดคล้องกัน แม้ว่ากระบวนการทํางานจํานวนมากจะทํางานผ่านอินเตอร์เฟซการเขียนโปรแกรมของแอปพลิเคชัน (API) การประสานงานยังคงครอบงําโดยไฟล์ปลายวันเนื่องจากพวกเขาให้ภาพฉบับที่สามารถตรวจสอบได้และสนับสนุนการประมวลผลซ้ําแบบวินิจฉัย ในขนาดข้อ จํากัด เหล่านี้ทรงกลมสถาปัตยกรรมมากขึ้นกว่ากลยุทธ์ทางธุรกิจ: การส่งไฟล์ที่ไม่ได้สมบูรณ์แบบและซ้ําซ้อน: ไฟล์มาช้าผิดปกติซ้ําซ้อนหรือแก้ไขดังนั้นท่อต้องสามารถทํางานได้และปลอดภัยในการเรียกใช้ใหม่ ตัวระบุไม่ได้จัดลําดับอย่างชัดเจน: การทําธุรกรรมเดียวกันสามารถนํา ID ที่แตกต่างกันไปทั่วทั้งบุคคลดังนั้นการจับคู่มักต้องใช้คีย์คอมโพสิตและกลยุทธ์ความสัมพันธ์ การกําหนดค่าที่หนัก: การคืนเงินข้อพิพาทค่าธรรมเนียมและการแก้ไขเปลี่ยนกฎการจับคู่ตามเวลาและเพิ่มการขยายตัวการเขียน การประมวลผลไฟล์ระยะยาวสามารถเกินขีด จํากัด การคํานวณระยะสั้นและปริมาณการเขียนสูงสามารถสร้างรูปแบบการเข้าถึงที่ไม่สม่ําเสมอและพาร์ทิชันร้อนในสต็อกข้อมูลการจับคู่ ในโพสต์นี้เราจะมุ่งเน้นไปที่ความท้าทายทางเทคนิคของการดัดแปลงทางการเงินโดยเฉพาะอย่างยิ่งการตรวจสอบสมดุลและการจับคู่การชําระเงินเครือข่ายและวิธีการที่เราออกแบบท่อไร้เซิร์ฟเวอร์ AWS ที่อยู่รอบข้อ จํากัด เหล่านี้ II. สถาปัตยกรรมที่ไม่มีเซิร์ฟเวอร์: decoupling และ orchestration ด้วยข้อ จํากัด เหล่านี้เรากําลังมุ่งมั่นที่จะใช้สถาปัตยกรรมแบบไร้เซิร์ฟเวอร์เพื่อลดค่าใช้จ่ายในการดําเนินงานเพิ่มความพร้อมใช้งานและสนับสนุนการปรับขนาดอัตโนมัติ วิธีการนี้ช่วยให้ทีมงานขนาดเล็กของเราสามารถทําซ้ําได้อย่างรวดเร็วและมุ่งเน้นความพยายามด้านวิศวกรรมของเราไปที่กลยุทธ์ทางธุรกิจทางการเงินที่ซับซ้อนแทนการบํารุงรักษาและการแก้ไขพื้นฐานซึ่งช่วยลดการพัฒนาและโปรไฟล์ค่าใช้จ่ายพื้นฐานของเราอย่างมีนัยสําคัญ เครื่องมือหลักของเราคือ และ เพื่อให้บทความเรียบง่ายและมุ่งเน้นเราจะมุ่งเน้นไปที่เอกสารทางการเงินเท่านั้น 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. การดูดซึมและการนําทางเหตุการณ์ (Amazon S3 และ Amazon EventBridge) กระบวนการเริ่มต้นเมื่อหนึ่งในไฟล์ (Transaction, Balance, or Network Settlement) จะถูกวางลงในโฟลเดอร์ Secure File Transfer Protocol (SFTP) ที่ซิงค์กับ S3 Buckets ในการออกแบบของเราเราได้นําเหตุการณ์ที่สร้างโดยวัตถุ S3 ผ่าน EventBridge แทนที่จะใช้การแจ้งเตือน S3 โดยตรง สิ่งนี้ทําให้เส้นทางการดูดซึมง่ายขึ้นเนื่องจากผู้ผลิตและผู้บริโภคยังคงเชื่อมโยงกันอย่างราบรื่น นอกจากนี้ยังให้เราสถานที่ที่สอดคล้องกันในการใช้กฎการกรองและการนําทางผ่านแหล่งต่างๆของเหตุการณ์ B. การประมวลผลที่ยั่งยืน (Amazon SQS) ในการออกแบบของเรากฎของ EventBridge มีวัตถุประสงค์เพื่อจัดลําดับมาตรฐานของ SQS เพื่อให้การระงับและแยกการดูดซับจากการประมวลผล การจัดลําดับนี้มีวัตถุประสงค์สําคัญสามประการ: Throttling / Load Leveling: มันเรียบขีดข่วนการดูดซึม ถ้าสามไฟล์ขนาดใหญ่มาพร้อมกันถัดไปดูดซึมโหลดช่วยให้มั่นใจว่าบริการการคํานวณด้านล่างของเราดึงข้อความในอัตราที่มั่นคงและยั่งยืนแทนที่จะถูกซับซ้อน ความทนทาน: ข้อความยังคงอยู่ใน SQS จนกว่าจะได้รับการประมวลผลอย่างประสบความสําเร็จซึ่งรับประกันการส่งมอบอย่างน้อยหนึ่งครั้ง Dead Letter Queue (DLQ) : ทุกแถว SQS จะมีการกําหนดค่าด้วย DLQ. หากการประมวลผล Lambda ไม่ประสบความสําเร็จอย่างต่อเนื่อง (เช่นเกินจํานวนการเรียกคืนสูงสุดของ 5) ข้อความจะถูกย้ายไปยัง DLQ สําหรับการตรวจสอบด้วยตนเองเพื่อให้ไม่มีธุรกรรมหายไปอย่างเงียบสงบ C. Compute Layer (AWS Lambda และ Amazon ECS) โครงสร้างพื้นฐานการคํานวณของเราถูกแบ่งออกอย่างกลยุทธ์เพื่อเพิ่มค่าใช้จ่ายและระยะเวลา: AWS Lambda: จัดการงานที่มีน้ําหนักเบาการระเบิดและการประสานงานเช่นการคัดลอกข้อความและการเปิดตัวแผนที่แบบขนานของฟังก์ชั่นขั้นตอน Lambda มีการเริ่มต้นเย็นอย่างรวดเร็วและมีค่าใช้จ่ายต่ําสําหรับงานขั้นตอนที่รับประกันจะเสร็จสมบูรณ์ภายใน 15 นาที AWS ECS Fargate: เก็บไว้สําหรับงานการประสานงานที่ต้องการหน่วยความจําสูงหรือเกินระยะเวลา Lambda 15 นาที (ขอบขอบขอบทั่วไปตามที่อธิบายไว้ในส่วน III) เราได้บรรจุกลยุทธ์การประสานงานหลักซึ่งช่วยให้เราสามารถย้ายงานที่ทํางานได้นานขึ้นและมีความเข้มข้นในการคํานวณไปยัง Fargate โดยไม่ต้องเขียนรหัสใหม่ D. Workflow Orchestration (AWS ขั้นตอนฟังก์ชั่น) การประสานงานเป็นกระบวนการทํางานที่ยาวนานและมักใช้เวลานานหลายวันดังนั้น AWS Step Functions เหมาะสําหรับการประสานงานแบบไร้เซิร์ฟเวอร์เพื่อประสานงานขั้นตอนการคํานวณแต่ละขั้นตอน เราเลือก Step Functions โดยเฉพาะอย่างยิ่งเนื่องจากให้ความทนทานและความอดทนต่อข้อบกพร่องที่ไม่ได้รับการเจรจาเพื่อความสอดคล้องทางการเงินโดยไม่จําเป็นต้องเขียนรหัสการแก้ไขที่ซับซ้อนและการจัดการสถานะ เหตุผลสําหรับการเลือกนี้มีรากฐานในความจําเป็นทางสถาปัตยกรรม: สถานะที่จัดการและความยั่งยืน: การประสานงานเกี่ยวข้องกับสิบขั้นตอนตามลําดับและตามลําดับ (การแบ่งแยกปกติการจับคู่รวม) ฟังก์ชั่นขั้นตอนเป็นหลักในการจัดการสถานะระหว่างขั้นตอนเมื่อบริการด้านล่างล้มเหลว (เช่นข้อผิดพลาด Lambda) State Machine ระงับติดตามจุดล้มเหลวที่แน่นอนและช่วยให้กระบวนการทํางานสามารถรีสตาร์ทหรือรีสตาร์ทได้จากจุดนี้ซึ่งเป็นสิ่งสําคัญสําหรับการตรวจสอบและกู้คืน การสอดคล้องกันอย่างมีนัยสําคัญผ่านสถานะแผนที่: ขึ้นอยู่กับกรณีการใช้ของเราเราทํางานงานบางอย่างใน paralel โดยใช้สถานะแบบ parallel และในทางคล้ายกันเมื่อเราต้องการสอดคล้องกับงานเดียวกันด้วยการป้อนข้อมูลที่แตกต่างกันเราใช้สถานะแผนที่ Debugging Visual และ Auditability: สําหรับความสอดคล้องและการดําเนินงานความสามารถในการดูภาพกระบวนการทํางานทั้งหมดเป็นสิ่งสําคัญ Step Functions ให้มุมมองกราฟิกของแต่ละขั้นตอนรวมถึงอินพุตเอาต์พุตและเหตุผลการล้มเหลว สิ่งนี้ทําให้เป็นเรื่องง่ายสําหรับทีม On-Call เพื่อติดตามสถานะของงานบางอย่างและเริ่มต้นการ debugging E. เคลือบเสถียรภาพ (Amazon DynamoDB) เราเลือก DynamoDB เป็นฐานข้อมูลหลักของเราสําหรับการจัดเก็บบันทึกการทําธุรกรรมและสมดุลที่ไม่สามารถเปลี่ยนแปลงได้เนื่องจากคุณสมบัติที่จําเป็นสําหรับโปรแกรมบัตรขนาดใหญ่: ปริมาณสูง, ความล่าช้าต่ํา: DynamoDB ได้รับการออกแบบมาเพื่อให้สามารถคาดการณ์ความล่าช้าเป็นมิลลิสวินาทีหนึ่งตัวได้ในปริมาณสูงซึ่งเป็นสิ่งจําเป็นสําหรับกระบวนการทํางานทางการเงิน เซิร์ฟเวอร์ไร้เซิร์ฟเวอร์และได้รับการจัดการ: โดยใช้ธรรมชาติที่ได้รับการจัดการอย่างเต็มที่เราได้กําจัดความเสียหายจากการจัดหาการแก้ไขและแบ่งฐานข้อมูลความสัมพันธ์แบบดั้งเดิม (MySQL / Postgres) ซึ่งช่วยให้เราสามารถมุ่งเน้นไปที่ความท้าทายในระดับแอพพลิเคชันเช่นการออกแบบคีย์พาร์ทิชัน การบูรณาการสตรีม: DynamoDB Streams เป็นสิ่งสําคัญที่ให้การเปลี่ยนแปลงที่เกิดขึ้นในเวลาจริงซึ่งจะกระตุ้นการปฏิบัติตามการวิเคราะห์และการจัดเก็บข้อมูล (Snowflake) ระบบ เวอร์ชันที่เรียบง่ายของกระแสบัตร debit ของเราดูเหมือนนี้ ในครึ่งหนึ่งด้านบนประมวลผลการส่งออกจะลดไฟล์เครือข่ายที่ซิงค์เข้ากับ S3 กฎของ EventBridge จะฟังเหตุการณ์ S3 ใหม่และส่งไปยังลําดับ SQS ที่ส่งออก Initiator Lambda จะสํารวจลําดับนี้อย่างต่อเนื่องและเปิดใช้งานฟังก์ชั่นขั้นตอนการชําระเงินเครือข่ายซึ่งจะวิเคราะห์ไฟล์การชําระเงินเครือข่ายและจัดเก็บข้อมูลที่วิเคราะห์ไว้ในตารางการชําระเงินเครือข่าย DynamoDB ในครึ่งล่างการไหลของ fintech เริ่มต้นเมื่อพันธมิตร fintech หยุดไฟล์การทําธุรกรรมและสมดุล สิ่งนี้จะเปิดใช้งานเหตุการณ์ที่ถูกนําทางผ่านสาย SQS ไปยัง Initiator Lambda ซึ่งจะเริ่มฟังก์ชั่นขั้นตอนที่แยกต่างหากซึ่งยืนยันและจับคู่ไฟล์กับข้อมูลการชําระเงินเครือข่าย กระบวนการนี้เรียกว่าการจับคู่เครือข่าย ในด้านขวาเรามีการจับคู่ FBO ซึ่งจับคู่ไฟล์สมดุลฟินเทคกับจํานวนเงินที่กําหนดไว้ในบัญชี FBO เพื่อสนับสนุนความถูกต้องแบบ End-to-End ในเครือข่าย FinTech และบันทึกธนาคาร III. The Scaling Battle: การเอาชนะขีด จํากัด ที่ไม่มีเซิร์ฟเวอร์ สถาปัตยกรรมนี้ทํางานได้ดีในตอนแรก แต่ในขณะที่ปริมาณของเราเติบโตเราได้สัมผัสกับสองขอบเขตที่สําคัญ: ระยะเวลาการคํานวณและการแบ่งฐานข้อมูลซึ่งบังคับให้เราพัฒนาวิธีการของเรา A. การเพิ่มประสิทธิภาพการคํานวณ: การย้าย Lambda-to-ECS การขัดขวางที่ทันทีที่สุดคือขีด จํากัด การดําเนินการ 15 นาทีของ Lambda ในขณะที่การแยกไฟล์ช่วยให้กลยุทธ์การจับคู่ที่ซับซ้อนผ่านชิ้นส่วนขนาดใหญ่ (เช่นบันทึก 20,000 ในไฟล์คอลัมน์กว้างความกว้างคงที่) ยังคงบางครั้งเกินหน้าต่างนี้ โซลูชันของเราไม่ใช่การออกแบบใหม่ แต่การเปลี่ยนสถาปัตยกรรมที่เรียบง่าย: ฐานโค้ดแบบรวม: เรารักษาตัวแทนประสานงานหลักเดียวแอพพลิเคชันที่เขียนในคอนเทนเนอร์ที่เขียนใน Go ซึ่งจัดการการแก้ไขและประมวลผลไฟล์ การดําเนินงานแบบไดนามิก: เราได้ใช้ภาพคอนเทนเนอร์นี้ทั้งใน Lambda (สําหรับการดําเนินงานที่รวดเร็วและเป็นระยะเวลา) และ ECS Fargate (สําหรับงานที่ทํางานเป็นเวลานานและใช้มวลหน่วยความจํา) การเลือกฟังก์ชั่นขั้นตอน: ฟังก์ชั่นขั้นตอนใช้สถานะการเลือกในช่วงต้นของกระบวนการ หากขนาดไฟล์ต่ํากว่าขอบเขตบางอย่าง (เช่น 1GB) จะมุ่งเน้นฟังก์ชั่น Amazon Lambda หากไฟล์มีขนาดใหญ่สถานะการเลือกจะเรียกร้องการบูรณาการฟังก์ชั่นขั้นตอนสําหรับ ECS (RunTask) เพื่อเริ่มต้นงาน Fargate ที่กําหนดเอง วิธีการนี้ให้เราสมดุลทางปฏิบัติ: ประหยัดค่าใช้จ่ายและความเร็วของ Lambda สําหรับ 90% ของไฟล์ขนาดเล็กและพื้นที่การคํานวณของ Fargate สําหรับ 10% ของธุรกรรมและไฟล์สมดุลที่มีการประมวลผลช้า B. Mastering DynamoDB สําหรับการเขียนความเร็วสูง DynamoDB เป็นทางเลือกที่ยอดเยี่ยมสําหรับฐานข้อมูลที่มีปริมาณสูงความต้องการความล่าช้าต่ําสําหรับการจัดเก็บธุรกรรม อย่างไรก็ตามความยืดหยุ่นของมันมีแนวโน้มที่จะกระจาย I / O อย่างสม่ําเสมอผ่านพาร์ทิชัน เราได้เริ่มเขียนอย่างรวดเร็วเนื่องจากพาร์ทิชันร้อน Throttling เกิดขึ้นเมื่อคีย์พาร์ทิชันเดียวเกินขีด จํากัด (ปกติ 1,000 หน่วยความจุการเขียน (WCU) หรือ 3,000 หน่วยความจุการอ่าน (RCU) ต่อวินาที) รูปแบบการเข้าถึงการจับคู่หลักของเราคือ: เรามีคีย์พาร์ทิชัน ProgramID#FileDate (เช่น PROGX#20250101) การออกแบบนี้ล้มเหลวเพราะการทําธุรกรรมทั้งหมดสําหรับโปรแกรมขนาดใหญ่ในวันเดียว , ข้ามขีด จํากัด WCU และย่อยอาหาร ค้นหาธุรกรรมทั้งหมดสําหรับโปรแกรมเฉพาะในวันที่เฉพาะเจาะจง ส่วนแบ่งเดียวกัน The Global Secondary Index (GSI) Backpressure Lesson: เราพยายามแก้ปัญหานี้โดยการย้ายคีย์หลักที่มีความสําคัญสูงไปยัง GSI และสอบถาม GSI แทนนั้น อย่างไรก็ตามสิ่งนี้ไม่ได้ให้การบรรเทา เนื่องจาก GSI ได้รับการไหลของข้อมูลจากตารางหลักหากพาร์ทิชันของตารางหลักได้รับการ throttled คู่ของการดูดซึมของ GSI จะได้รับ GSI backpressure ซึ่งในที่สุดจะ จํากัด การเขียนผ่านของตารางทั้งหมด เราสังเกตเห็นว่าปัญหาคีย์พาร์ทิชันหลักต้องได้รับการแก้ไขในระดับตารางราก การออกแบบคีย์ที่เพิ่มประสิทธิภาพ: การแบ่งคีย์พาร์ทิชัน แก้ไขของเราคือการแนะนําการตัดการเขียนสําหรับลูกค้าที่มีปริมาณมากที่สุดของเรา: PK Sharding: เราได้เพิ่มหมายเลข shard ที่คํานวณไปยังคีย์พาร์ทิชัน: ProgramID#FileDate#ShardN โลจิสติก Sharding: เราใช้อัลกอริทึม hashing น้ําหนักเบา (เช่น modulo) บน TransactionID เพื่อให้มันเป็น shard (เช่น TransactionID % 10 ผลในหมายเลข shard ระหว่าง 0 และ 9) ผลลัพธ์: นี้แพร่กระจายโหลดการเขียนผ่านสิบพาร์ทิชันทางกายภาพแทนหนึ่งซึ่งจะบรรเทาปัญหาพาร์ทิชันที่ร้อนและช่วยให้เราสามารถดูดซับข้อมูลในอัตราที่สูงกว่า 10 เท่า IV. บทเรียนที่สามารถทําได้เรียนรู้ ส่วนนี้สรุปรูปแบบที่คุณสามารถนําไปใช้กับท่อประสานงานของคุณเองด้วยตัวอย่างจากการใช้งานของเรา A. การออกแบบระบบบทเรียน นี่คือสามบทเรียนการออกแบบระบบที่คุณสามารถประยุกต์ใช้เมื่อคุณสร้างท่อประสานงานที่ต้องจัดการกับ retries อินพุตที่ไม่สมบูรณ์แบบและระบบภายนอกหลายระบบ: 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. บทเรียนการดําเนินงานที่ยอดเยี่ยม บทเรียนการดําเนินงานเหล่านี้คือการลดเวลาในการตรวจจับและเวลาในการแก้ไขโดยการทําให้ความล้มเหลวเห็นได้ง่ายและสามารถตรวจสอบได้ง่ายสําหรับทั้งทีมและพันธมิตรของคุณ มุ่งเน้นไปที่ความสามารถในการสังเกตภายใน: เราพบว่าวัฒนธรรมของความสามารถในการสังเกตได้ดีกว่าการแก้ไขปัญหาอย่างต่อเนื่อง ความมุ่งเน้นของเราเปลี่ยนจากการตอบสนองต่อข้อผิดพลาดไปสู่การยับยั้งพวกเขาซึ่งจําเป็นต้องมีทฤษฎีการดําเนินงานทั่วคณะกรรมการ หลักในการทําเช่นนี้คือการระบุ hotspots ของเราล่วงหน้า (การตั้งค่าเตือนภัยที่เข้มงวดและขอบเขตสําหรับเมตริกเช่นความลึกลําดับ SQS และ DynamoDB throttling) โดยการตั้งค่าวัตถุประสงค์ระดับบริการที่จําเป็น (SLO) มุ่งเน้นไปที่ความสามารถในการสังเกตภายนอก: คุณควรทําให้ความล้มเหลวในการประสานงานสามารถดําเนินการได้แก่ลูกค้าโดยการกลับข้อความข้อผิดพลาดที่ชัดเจนและให้บริการด้วยตนเองและคําแนะนํา ในการใช้งานของเราเราได้มาตรฐานรหัสข้อผิดพลาดและให้พื้นผิวที่เพียงพอสําหรับพันธมิตรเพื่อแก้ปัญหาทั่วไปโดยไม่ต้องเพิ่มการสนับสนุน การลงทุนในเครื่องมือ: สร้างเครื่องมือการสํารวจในตอนแรกเพื่อให้คุณสามารถติดตามความไม่สอดคล้องกับไฟล์แหล่งข้อมูลการทํางานของการประมวลผลและการเขียนที่เกิดขึ้นโดยไม่ต้องเจาะผ่านบันทึก ดังนั้นการคัดกรองยังคงรวดเร็วและสอดคล้องกันแม้เมื่อปริมาณเพิ่มขึ้นหรือผู้ตรวจสอบถามคําถาม มุ่งเน้นไปที่ความเร็วในการรับความคิดเห็น: คุณควรเพิ่มประสิทธิภาพสําหรับการตอบสนองที่รวดเร็ว การเปิดใช้งานที่รวดเร็วโดยไม่ต้องเซิร์ฟเวอร์และค่าใช้จ่ายในการพัฒนาที่ต่ํา หลังจากเดือนแรกของเราในการทํางานของระบบการจับคู่ที่เกิดเหตุการณ์นี้ค่าธรรมเนียมการคํานวณคลาวด์ทั้งหมดของเราน้อยกว่าค่าธรรมเนียมอาหารกลางวันของทีมของเรา อาร์คไทเทเนียมนี้ช่วยให้ทีมงานขนาดเล็กของเราสามารถทําซ้ําได้อย่างรวดเร็วและมุ่งเน้นไปที่กลยุทธ์ทางการเงินที่ซับซ้อนแทนที่จะมุ่งเน้นพื้นฐาน C. การออกแบบอินเตอร์เฟซ: File vs. API ข้อผิดพลาดที่พบบ่อยคือการตั้งค่าอินเตอร์เฟซที่ใช้ไฟล์เมื่อ API เหมาะสําหรับกระบวนการทางธุรกิจ ใช้อินเทอร์เฟซที่เหมาะสมสําหรับปัญหา: ไม่มีคําตอบที่ถูกต้องที่นี่; คุณต้องคิดผ่านสิ่งที่คําอธิบายที่เหมาะสมคือการแก้ปัญหา เราใช้ไฟล์เฉพาะสําหรับการดําเนินงานแบบพาร์ติชันที่แท้จริงเมื่อการถ่ายภาพในตอนท้ายของวันเป็นความต้องการ (เช่น การจัดระเบียบเครือข่าย) จากนั้นเราใช้ API สําหรับทุกสิ่งอื่น ๆ โดยเฉพาะอย่างยิ่งเมื่อจําเป็นต้องมีการส่งข้อมูลแบบเรียลไทม์หรือการถ่ายโอนข้อมูลขนาดเล็กและแยกต่างหาก เราต้องเขียนใหม่หลายอินเทอร์เฟซภายในจากการอัปโหลดแบบไฟล์ไปยัง API HTTP เนื่องจากการดําเนินการด้านบนของการติดตามการประมวลผลและการแก้ไขปัญหาของไฟล์ขนาดเล็กจํานวนมากจึงซับซ้อนมากขึ้นกว่าการเรียกใช้ API ง่าย รักษาแผนไฟล์เช่นสัญญารุ่น: คุณควรปฏิบัติกับแผนไฟล์เป็นสัญญารุ่นเนื่องจากการเปลี่ยนแปลงเล็กน้อยสามารถทําลายการแก้ไขและขัดแย้งผลการเปรียบเทียบอย่างเงียบ ๆ ในท่อของเราเราได้แนะนําการยืนยันแผนภูมิอย่างชัดเจนและการตรวจสอบการแก้ไขรุ่นเพื่อลดเหตุการณ์ที่เกิดจากการเปลี่ยนแปลงรูปแบบขึ้นไป ข้อสรุป การสร้างระบบประสานงานที่ปรับขนาดบน AWS นั้นไม่ใช่เรื่องการเลือกส่วนประกอบที่ไม่มีเซิร์ฟเวอร์ แต่เป็นเรื่องการออกแบบสําหรับความล้มเหลวการเล่นซ้ําและการสํารวจ ในการใช้งานของเราบริการที่ไม่มีเซิร์ฟเวอร์ของ AWS ให้พื้นฐานที่แข็งแกร่งสําหรับการจัดระเบียบและสภาพที่ยั่งยืน ผลการผลิตในที่สุดขึ้นอยู่กับรายละเอียดโดยเฉพาะอย่างยิ่งความสามารถในการออกแบบกุญแจส่วนแบ่งและสัญญาณการดําเนินงานที่ทําให้ข้อผิดพลาดสามารถตรวจจับและแก้ไขได้อย่างรวดเร็ว