Stripe को सिर्फ एक संख्या चाहिए

 (blog.exe.dev)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • exe में प्रोडक्ट लॉजिक के अलग-अलग हिस्सों से payment API को सीधे कॉल करने के बजाय, state changes को billable facts के रूप में रिकॉर्ड किया जाता है और final state को Stripe के साथ reconcile किया जाता है
  • पुरानी संरचना में database transaction और payment API calls आपस में उलझे हुए थे, इसलिए partial failure, असामान्य subscription state, और payment decline जैसी exceptions प्रोडक्ट flow को भी हिला देती थीं
  • जब team seats जोड़ी जाती हैं, तो state को dirty के रूप में mark किया जाता है, और बाद का worker business rules के अनुसार quantity निकालकर सिर्फ बदलाव होने पर Stripe subscription quantity अपडेट करता है
  • payment को अलग करने पर नए team member onboarding को payment code पर निर्भर नहीं रहना पड़ता, और seat calculation rules बदलने पर भी invite और join flow प्रभावित नहीं होते
  • इसी reconciliation structure को active VM और disk usage जैसे usage-based billing और iOS in-app purchases पर भी लागू किया गया, ताकि product events वैसे ही रहें और सिर्फ payment provider के हिसाब से integration बदला जाए

प्रोडक्ट flow से payment logic को अलग करना

  • जब payment logic सामान्य business logic के साथ मिल जाता है, तो billing से जुड़ा code उन सभी critical paths में फैल जाता है जहां billing की जरूरत होती है, और pricing structure भी नाजुक हो जाती है, जिससे उसे बदलना मुश्किल हो जाता है
  • exe का लक्ष्य यह है कि payment knowledge किसी एक व्यक्ति तक सीमित न रहे और कोई भी संबंधित code बदल सके, जबकि complex exceptions को specialist संभाले
  • शुरुआत में team seat billing, invite accept करने से लेकर payment तक, एक बड़े flow में बंधी हुई थी
    • user invite accept करता है, account verify करता है, और फिर team join करता है
    • उसे shared VM access और plan के अनुसार compute resources allocate किए जाते हैं
    • इसी process में payment API भी call किया जाता है
  • database changes और external API calls को इस तरह जोड़ने पर partial failure हो सकता है, जहां सिर्फ एक पक्ष सफल हो
    • team subscription state असामान्य हो सकती है
    • अतिरिक्त seats के payment को reject किया जा सकता है
    • जैसे-जैसे exceptions बढ़ती हैं, पूरी संरचना और नाजुक हो जाती है

billable facts और बाद की reconciliation

  • billable facts atomic operations हैं जो दिखाते हैं कि कोई खास state बदल गई है
    • पहले product logic चलाकर resources की नई state को final किया जाता है
    • उसके बाद final facts के आधार पर payment provider की state को reconcile किया जाता है
    • Stripe को उस state तक पहुंचने की process नहीं, सिर्फ final quantity चाहिए

  • team seat reconciliation

    • invite accept होते ही team seat state को dirty mark किया जाता है
    • बाद का worker dirty state को detect करता है और business rules के अनुसार seat increase/decrease की गणना करता है
    • सिर्फ quantity बदलने पर ही Stripe की subscription quantity अपडेट की जाती है
    • team member addition और payment code अलग होने से invite flow को दोबारा लिखने पर billing साथ में नहीं टूटती, और seat calculation का तरीका भी स्वतंत्र रूप से बदला जा सकता है

  • usage-based billing और in-app purchases

    • यही reconciliation process सभी usage-based billing पर लागू होती है
      • system active VM और disk usage से जुड़े facts रिकॉर्ड करता है
      • metering worker इन्हें payment provider की state के साथ reconcile करता है
      • नई billing methods जोड़ने पर भी facts वैसे ही रहते हैं, सिर्फ हर API के साथ reconcile करने का तरीका बदलता है
    • iOS app भी सिर्फ यह fact भेजता है कि किसी ने in-app purchase के जरिए subscription लिया, और असली payment state बाद में reconcile की जाती है
    • payment structure अब ऐसा क्षेत्र बन गया है जिसे दूसरे team members भी संभाल सकते हैं, और invite flow जैसे product features में बदलाव से billing system को नुकसान पहुंचने की संभावना भी कम हो गई है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs की राय

  • लेख का मुख्य बिंदु, बदलावों को asynchronously पहचानकर प्रोसेस करने का तरीका, coupling को कम करने और side effects को लागू करने के लिए अच्छा है
    लेकिन LLM ऐसा टूल है जो कोड के जगह-जगह फैलने की समस्या को रोकने के बजाय उसे तेज़ करता है, इसलिए यह आसानी से architectural debt बन सकता है। जो कोड हमारी समझने की रफ़्तार से भी तेज़ बन रहा हो, उसका review कैसे किया जा सकता है, यह भी सवाल है; और Exe में कोड review भी नहीं होता, यह बात और भी डरावनी है

    • यह याद रखना चाहिए कि tech industry, जो पहले भी बहुत गंभीर नहीं थी, अभी खास तौर पर गैर-गंभीर दौर से गुज़र रही है
    • billing system संभालने के नज़रिए से यह काफ़ी डरावना approach है। billing platform कई स्पष्ट सीमाओं वाले contexts से बना होता है, लेकिन LLM domain boundaries को ठीक से नहीं निभा पाते, इसलिए बड़े दर्द की संभावना है
    • मुझे लगा था बात “LLM का इस्तेमाल करने पर भी” की नहीं, बल्कि “खासकर LLM का इस्तेमाल करने पर” कोड और ज़्यादा फैलता है
    • उस उद्धरण को मैं Orwell का नहीं बल्कि Upton Sinclair का कथन मानता हूँ

  • यह architecture दिलचस्प तो है, लेकिन लेख की शुरुआत में उठाई गई समस्या को यह कैसे हल करता है, यह स्पष्ट नहीं है। अगर payment decline हो जाए, तो ऐसा लगता है कि यह सभी resources का payment सुनिश्चित करने के बजाय पहले unpaid resources उपलब्ध करा देगा
    billing worker declined तथ्य publish करके resources वापस ले सकता है, लेकिन साफ़ one-way flow की तुलना में यह एक circular structure बन जाता है। Exe जैसी monthly billing वाली computing service के लिए यह ठीक बैठ सकता है, लेकिन physical equipment ship करने या किसी और service की seats दोबारा बेचने वाले business में इसे स्वीकार करना मुश्किल compromise है

    • यह एक abstract और replaceable software-केंद्रित billing मॉडल है। usage-based billing में बेहतर यह है कि chargeable events होने का analytics data आधार बने, और billing system उसे aggregate करके consistent invoice details बनाए। chargeable events कई जगहों पर बन सकते हैं, इसलिए उन्हें product code के बाहर अलग करना भी स्वस्थ तरीका है
      लेकिन API calls या database transactions fail होने पर, abnormal subscription state होने पर, या seat payment decline होने पर क्या होगा, इसका सीधा जवाब यह नहीं देता। refactoring से analytics collection टूट जाना, किसी row को अब changed state के रूप में mark न करना, या किसी नए path में change marking छूट जाना—ये समस्याएँ भी जस की तस रहती हैं
      seats·free quota limits, max spend settings, prepaid balance deduction जैसी product के अंदर मौजूद billing-संबंधित state भी यह हल नहीं करता। product service events publish कर सकती है और billing service compliance state वापस product में reflect कर सकती है, लेकिन तब state वाले distributed system में दो actors हो जाते हैं

  • Stripe भले सिर्फ़ एक number चाहता हुआ लगे, लेकिन एक निश्चित scale पर payment के line-item details भी देने से interchange fees कम की जा सकती हैं और approval rate बढ़ाया जा सकता है

  • Exe का बिना code review वाला तरीका नया लगता है। ऐसे में यह जानने की जिज्ञासा है कि release और testing किस तरह चलाए जाते हैं