Yang Diinginkan Stripe Hanyalah Satu Angka

• Alih-alih memanggil API pembayaran secara langsung di berbagai bagian logika produk, exe mencatat perubahan status sebagai fakta yang dapat ditagih (billable facts) dan merekonsiliasi status yang sudah final dengan Stripe
• Dalam struktur lama, transaksi database dan pemanggilan API pembayaran saling terjalin, sehingga pengecualian seperti kegagalan parsial, status langganan yang tidak normal, dan penolakan pembayaran ikut mengguncang alur produk
• Saat seat tim ditambahkan, status ditandai sebagai dirty, lalu worker berikutnya menghitung jumlah berdasarkan aturan bisnis dan memperbarui jumlah langganan Stripe hanya jika ada perubahan
• Dengan memisahkan pembayaran, onboarding anggota tim baru tidak bergantung pada kode pembayaran, dan perubahan aturan perhitungan seat tidak memengaruhi alur undangan maupun pendaftaran
• Struktur rekonsiliasi yang sama juga diterapkan pada penagihan berbasis pemakaian seperti VM aktif dan penggunaan disk, serta pembelian dalam aplikasi iOS, sehingga event produk tetap dipertahankan sementara yang berubah hanya integrasi per penyedia pembayaran

---

Memisahkan Logika Pembayaran dari Alur Produk

• Jika logika pembayaran bercampur dengan logika bisnis umum, kode terkait akan tersebar di semua jalur inti yang membutuhkan penagihan, dan struktur harga menjadi rapuh serta sulit diubah
• exe ingin agar pengetahuan tentang pembayaran tidak dimonopoli oleh satu orang dan siapa pun dapat mengubah kode terkait, sementara pengecualian yang kompleks ditangani oleh penanggung jawab khusus
• Penagihan awal untuk seat tim sebelumnya diikat sebagai satu alur besar, mulai dari penerimaan undangan hingga pembayaran
  • Pengguna menerima undangan, memverifikasi akun, lalu bergabung ke tim
  • Pengguna memperoleh hak akses ke VM bersama dan resource komputasi sesuai paket
  • Dalam proses ini, API pembayaran juga dipanggil
• Menggabungkan perubahan database dengan pemanggilan API eksternal seperti ini dapat menyebabkan kegagalan parsial, ketika hanya salah satu sisi yang berhasil
  • Status langganan tim bisa menjadi tidak normal
  • Pembayaran untuk seat tambahan bisa ditolak
  • Semakin banyak pengecualian menumpuk, semakin rapuh keseluruhan struktur

Fakta yang Dapat Ditagih dan Rekonsiliasi Setelahnya

• Fakta yang dapat ditagih adalah operasi atomik yang menunjukkan bahwa status tertentu telah berubah
  • Jalankan logika produk terlebih dahulu untuk menetapkan status baru resource
  • Setelah itu, rekonsiliasikan status penyedia pembayaran berdasarkan fakta yang sudah final
  • Stripe hanya membutuhkan jumlah akhir, bukan proses untuk mencapai status tersebut

• Rekonsiliasi Seat Tim

  • Saat undangan diterima, status seat tim ditandai sebagai dirty
  • Worker berikutnya mendeteksi status dirty dan menghitung kenaikan atau penurunan seat berdasarkan aturan bisnis
  • Jumlah langganan di Stripe diperbarui hanya jika jumlahnya berubah
  • Karena penambahan anggota tim dipisahkan dari kode pembayaran, penagihan tidak ikut rusak meski alur undangan ditulis ulang, dan cara menghitung seat juga dapat diubah secara independen

• Penagihan Berbasis Pemakaian dan Pembelian Dalam Aplikasi

  • Proses rekonsiliasi yang sama berlaku untuk semua penagihan berbasis pemakaian
    • Sistem mencatat fakta tentang VM aktif dan penggunaan disk
    • Worker pengukuran merekonsiliasikannya dengan status penyedia pembayaran
    • Sekalipun cara penagihan baru ditambahkan, faktanya tetap dipertahankan, dan yang berubah hanya cara rekonsiliasi dengan masing-masing API
  • Aplikasi iOS juga hanya menyampaikan fakta bahwa seseorang berlangganan melalui pembelian dalam aplikasi, sementara status pembayaran sebenarnya direkonsiliasi kemudian
  • Struktur pembayaran menjadi area yang dapat ditangani oleh anggota lain, dan kemungkinan perubahan fitur produk seperti alur undangan merusak sistem penagihan juga menurun

[GN⁺]

Opini di Lobste.rs

• Poin utama tulisan ini, yaitu cara mendeteksi dan memproses perubahan secara asinkron, bagus untuk menurunkan coupling dan mengimplementasikan efek samping
  Namun, LLM adalah alat yang cenderung mempercepat, bukan mencegah, fenomena kode yang tersebar ke mana-mana, sehingga mudah menjadi utang arsitektur. Juga muncul pertanyaan bagaimana kode yang dihasilkan lebih cepat daripada kemampuan kita memahaminya bisa ditinjau dengan baik, dan bagian bahwa Exe bahkan tidak melakukan code review terasa lebih mengkhawatirkan

  • Perlu diingat bahwa industri teknologi, yang sejak awal jarang benar-benar serius, sekarang sedang melewati masa yang sangat tidak serius
  • Dari sudut pandang orang yang menangani sistem penagihan, ini pendekatan yang cukup menakutkan. Platform penagihan terdiri dari beberapa konteks dengan batas yang jelas, tetapi LLM tidak pandai menjaga batas domain, jadi sangat mungkin menimbulkan penderitaan besar
  • Saya sempat berpikir, bukan “meski memakai LLM”, tetapi “justru kalau memakai LLM” kode akan semakin tersebar
  • Setahu saya, kutipan itu bukan dari Orwell melainkan dari Upton Sinclair

• Arsitektur ini memang menarik, tetapi tidak jelas bagaimana ia menyelesaikan masalah yang diajukan di awal tulisan. Jika pembayaran ditolak, tampaknya sistem ini akan lebih dulu menyediakan resource yang belum dibayar alih-alih menjamin pembayaran untuk semua resource
  Pekerja penagihan bisa saja menerbitkan fakta declined lalu menarik kembali resource, tetapi dibanding alur satu arah yang rapi, ini menjadi struktur sirkular. Ini mungkin cocok untuk layanan komputasi yang ditagih bulanan seperti Exe, tetapi merupakan kompromi yang sulit diterima bagi bisnis yang mengirim perangkat fisik atau menjual kembali seat layanan lain

  • Produknya adalah model penagihan berbasis software yang abstrak dan dapat dipertukarkan. Penagihan berbasis penggunaan bertumpu pada data analitik bahwa peristiwa penagihan telah terjadi, dan lebih baik jika sistem penagihan mengagregasikannya menjadi rincian tagihan yang konsisten. Karena peristiwa penagihan bisa muncul dari banyak tempat, memisahkannya ke luar kode produk juga sehat
    Namun, tulisan itu tidak menjawab secara langsung bagaimana menangani kegagalan panggilan API atau transaksi database, status langganan yang abnormal, atau penolakan pembayaran seat. Masalah seperti pengumpulan analitik yang rusak karena refactoring, baris tertentu yang tidak lagi ditandai sebagai berubah, atau jalur baru yang lupa memberi penanda perubahan juga tetap ada
    Ini juga tidak menyelesaikan status terkait penagihan yang berada di dalam produk, seperti batas seat/kuota gratis, pengaturan pengeluaran maksimum, atau pengurangan saldo prabayar. Layanan produk bisa menerbitkan event dan layanan penagihan bisa memantulkan kembali status kepatuhan ke produk, tetapi kalau begitu akan ada dua pelaku dalam sistem terdistribusi yang sama-sama memiliki state

• Stripe tampaknya hanya menginginkan satu angka, tetapi pada skala tertentu, menyediakan item rincian pembayaran juga bisa mengurangi biaya interchange dan meningkatkan tingkat persetujuan

• Cara Exe tidak melakukan code review terasa segar. Kalau begitu, saya penasaran bagaimana mereka menjalankan rilis dan pengujian