ระบบของคุณถือเงินไว้ ระบบของเราถือการคำนวณ
แพลตฟอร์มคือการคำนวณและบันทึกหนึ่งชุด มันรับสิ่งที่เกิดขึ้นในระบบของคุณ คำนวณว่าค้างจ่ายเท่าไร แล้วส่งคำสั่งกลับไป มันไม่เคยนั่งอยู่ในเส้นทางของเงิน
สเปกที่เผยแพร่ไว้ และไคลเอนต์สองตัวที่เขียนตามมัน
เอกสาร OpenAPI ในรีโพ ไคลเอนต์ TypeScript และไคลเอนต์ Dart วิศวกรของคุณอ่านผิวสัมผัสทั้งหมดได้ก่อนที่ใครจะนัดประชุม
OpenAPI
api/openapi.yaml
ไคลเอนต์ TypeScript
sdk/typescript
ไคลเอนต์ Dart
sdk/dart
เหตุการณ์ที่วางใจได้ว่าจะส่งถึง
เหตุการณ์สิบเอ็ดชนิด เข้าคิวในทรานแซกชันเดียวกับการเปลี่ยนสถานะที่ทำให้มันเกิด
- 01
เอาต์บ็อกซ์แบบทรานแซกชัน ไม่ใช่ POST แบบยิงแล้วลืม
เหตุการณ์ถูกเขียนในทรานแซกชันที่ทำให้มันเกิด แล้วค่อยถูกส่งออกจากคิวแบบมีสัญญาเช่า ไม่มีช่วงเวลาที่ระบบของคุณถูกแจ้งเรื่องที่บัญชีย้อนกลับไปแล้ว และไม่มีช่วงที่บัญชีลงเรียบร้อยแต่ไม่มีใครถูกแจ้งinternal/outbox
- 02
ลงลายเซ็น พร้อมรหัสกุญแจที่หมุนได้
ทุกการส่งพกลายเซ็น HMAC-SHA256 พร้อมรหัสกุญแจและเวลาประทับ การหมุนคาบเกี่ยวกัน: กุญแจเดิมยังใช้ได้ระหว่างที่คุณย้าย การหมุนความลับจึงไม่ใช่การหยุดระบบที่ต้องจัดตารางinternal/outbox/sign.go
- 03
เหตุการณ์การจ่ายไปก่อน
คำสั่งถอนไม่ได้ต่อคิวอยู่หลังกองแจ้งเตือน ชั้นการส่งเป็นเลนแยกกัน และการจ่ายคือเลนที่แบกคำสั่งเรื่องเงินinternal/events
- 04
รหัสแบบกำหนดแน่ การรันซ้ำจึงไม่เกิดผลซ้อน
การรันตัวจัดการซ้ำจะเข้าคิวรหัสเหตุการณ์เดิม ซึ่งเอาต์บ็อกซ์จะตัดซ้ำให้ นี่คือการส่งแบบอย่างน้อยหนึ่งครั้งที่คุณลองใหม่ได้จริง ไม่ใช่แบบที่คุณต้องคอยระวังinternal/events · internal/outbox
- 05
ด่านขาออกบน URL ของคุณ
ปลายทางตั้งค่าโดยผู้ดำเนินโปรแกรม ซึ่งทำให้มันเป็นช่องทาง SSRF โดยธรรมชาติ ตัวส่งจะตรวจ URL ก่อนยิงคำขอ และบล็อกที่อยู่ที่คุณคาดว่ามันควรบล็อกinternal/outbox/ssrf.go
- 06
ถอยรอ พักไว้ และตัวกระทบยอด
ความล้มเหลวจะถอยรอถี่ห่างขึ้นเรื่อย ๆ แล้วพักไว้ แทนที่จะกระหน่ำยิงปลายทางที่ล่มอยู่ ตัวกระทบยอดข้ามระบบจะจับเหตุการณ์ที่หายไปจริง ๆ แทนที่จะเชื่อว่าคิวสมบูรณ์แบบinternal/outbox · internal/reconciler
คำสั่งที่ทำงานครั้งเดียวเป๊ะ โดยใช้รหัสรายการของคุณเป็นกุญแจ
คุณบอกแพลตฟอร์มว่ามีการซื้อ มีการคืนเงิน มีสมาชิกผ่านการยืนยันตัวตน การส่งซ้ำไม่มีต้นทุน เพราะกุญแจเป็นของคุณ
ทุกคำสั่งขาเข้าทำซ้ำได้โดยไม่เกิดผลซ้อนต่อพื้นที่ทำงานและรหัสอ้างอิงหนึ่ง ๆ และคำตอบถูกแคชไว้ ส่งการซื้อเดิมสองครั้ง การเรียกครั้งที่สองจะคืนคำตอบของครั้งแรก — ไม่สร้างการซื้อที่สอง และไม่จ่ายค่าคอมมิชชันรอบที่สองจากการซื้อแรก
สัญญาเรื่องข้อผิดพลาดระบุไว้ชัด เพราะ “จะลองใหม่หรือไม่” คือคำถามที่การเชื่อมต่อฝั่งไคลเอนต์ต้องตอบจริง ๆ ข้อผิดพลาดที่ส่งกลับจะปล่อยใบรับ และคุณลองใหม่ได้ ส่วนการปฏิเสธด้วยรหัส 4xx คือจุดจบและถูกแคช: คำสั่งนั้นถูกปฏิเสธด้วยเนื้อหาของมันเอง ส่งใหม่ก็จะถูกปฏิเสธอีก
internal/commands · internal/command
จ่ายด้วยวิธีที่คุณจ่ายอยู่แล้ว
แพลตฟอร์มจองรายการในบัญชีแยกประเภทอย่างเจาะจงแล้วสั่งการ ส่วนตัวที่ลงมือจ่ายเป็นของคุณ
ถ้าคุณมีระบบจ่ายเงิน มันจะได้รับคำสั่งถอนเป็นเหตุการณ์ชั้นการจ่าย แล้วเรียกกลับมาว่าจ่ายสำเร็จหรือล้มเหลว ถ้าไม่มี คอนโซลการจ่ายจะแสดงรายการที่ค้าง คุณจ่ายจากกระเป๋าเงินของตัวเอง แล้วบันทึกราคาที่ทำรายการจริงและรหัสธุรกรรมของคุณเอง การจ่ายที่บันทึกโดยไม่มีรหัสอ้างอิงจะถูกปฏิเสธ — มันกระทบยอดกับกระเป๋าเงินของคุณไม่ได้เลย การรับไว้จึงแปลว่าการกระทบยอดจะพังในภายหลังและไกลออกไปเท่านั้น
internal/claims · internal/httpapi/payouts.go
โดเมนของคุณเอง พิสูจน์ก่อนจึงเปิดใช้
อ้างสิทธิ์ชื่อโฮสต์ เผยแพร่เรกคอร์ด TXT ที่แพลตฟอร์มสร้างให้ แล้วระบบจะเปิดใช้เมื่อเรกคอร์ดนั้นตอบกลับได้
ลำดับสำคัญ และนั่นคือประเด็นทั้งหมด การผูกชื่อโฮสต์ — หรือการเพิ่มโดเมนเข้ารายการที่อนุญาตของผู้ให้บริการยืนยันตัวตน — ก่อนพิสูจน์การควบคุม จะทำให้คนที่เป็นเจ้าของชื่อนั้นจริง ๆ ได้รับการเข้าสู่ระบบที่ควรเป็นของคุณ ดังนั้นจะไม่มีอะไรถูกเปิดใช้ และไม่มีอะไรถูกเพิ่มเข้ารายการอนุญาตให้เข้าสู่ระบบ จนกว่าเรกคอร์ดจะตอบกลับได้ ตัวเปิดใช้เบื้องหลังจะรับไปทำภายในหนึ่งนาที
internal/domains
หยิบแซนด์บ็อกซ์ไปต่อกับระบบสเตจจิงของคุณ
ฟรีในทุกแพ็กเกจ ด้วยผิวสัมผัส API เดียวกัน เหตุการณ์เดียวกัน และลายเซ็นเดียวกันกับระบบจริง