Stripe’ın istediği tek şey tek bir sayı

• exe, ürün mantığının çeşitli yerlerinde ödeme API’sini doğrudan çağırmak yerine, durum değişikliklerini faturalandırılabilir olgular (billable facts) olarak kaydediyor ve kesinleşmiş durumu Stripe ile mutabık hale getiriyor
• Mevcut yapıda veritabanı işlemleriyle ödeme API’si çağrıları iç içe geçtiği için kısmi başarısızlıklar, anormal abonelik durumları ve ödeme reddi gibi istisnalar ürün akışını bile sarsıyordu
• Ekip koltuğu eklendiğinde durum dirty olarak işaretleniyor; ardından çalışan bir worker, iş kurallarına göre miktarı hesaplayıp yalnızca değişiklik varsa Stripe abonelik miktarını güncelliyor
• Ödemeyi ayrıştırmak, yeni ekip üyesi onboarding sürecinin ödeme koduna bağımlı olmamasını sağlar; koltuk hesaplama kuralları değişse bile davet ve kayıt akışları etkilenmez
• Aynı mutabakat yapısı, aktif VM’ler ve disk kullanımı gibi kullanıma dayalı faturalandırma ile iOS uygulama içi satın almalara da uygulanarak, ürün olayları korunurken yalnızca ödeme sağlayıcısına özel entegrasyonların değiştirilebilmesini sağlar

---

Ödeme mantığını ürün akışından ayırmak

• Ödeme mantığı genel iş mantığıyla iç içe geçtiğinde, faturalandırma gerektiren tüm kritik yollara ilgili kod yayılır; fiyatlandırma yapısı da kırılganlaşır ve değiştirilmesi zorlaşır
• exe, ödeme bilgisinin tek bir kişinin tekelinde olmadığı, herkesin ilgili kodu değiştirebildiği; ancak karmaşık istisnaların uzman sorumlular tarafından ele alındığı bir yaklaşımı hedefliyor
• İlk ekip koltuğu faturalandırması, davetin kabulünden ödemeye kadar tek büyük akış olarak birbirine bağlanmıştı
  • Kullanıcı daveti kabul eder, hesabını doğrular ve ardından ekibe katılır
  • Paylaşılan VM erişim yetkisi ve plana göre bilgi işlem kaynakları atanır
  • Bu süreçte ödeme API’si de çağrılır
• Veritabanı değişikliklerini harici API çağrılarıyla bu şekilde birleştirmek, yalnızca bir tarafın başarılı olduğu kısmi başarısızlıklara yol açabilir
  • Ekip abonelik durumu anormal olabilir
  • Ek koltuk için ödeme reddedilebilir
  • İstisnalar biriktikçe tüm yapı kırılganlaşır

Faturalandırılabilir olgular ve sonradan mutabakat

• Faturalandırılabilir olgu, belirli bir durumun değiştiğini gösteren atomik bir işlemdir
  • Önce ürün mantığı çalıştırılır ve kaynağın yeni durumu kesinleştirilir
  • Ardından kesinleşmiş olguya dayanarak ödeme sağlayıcısının durumu mutabık hale getirilir
  • Stripe’ın o duruma nasıl gelindiğine değil, yalnızca nihai miktara ihtiyacı vardır

• Ekip koltuğu mutabakatı

  • Davet kabul edildiğinde ekip koltuğu durumu dirty olarak işaretlenir
  • Ardından çalışan bir worker dirty durumunu algılar ve iş kurallarına göre koltuk artış/azalışını hesaplar
  • Yalnızca miktar değiştiyse Stripe’taki abonelik miktarı güncellenir
  • Ekip üyesi ekleme ile ödeme kodu ayrıldığı için davet akışı yeniden yazılsa bile faturalandırma bununla birlikte bozulmaz; koltuk hesaplama yöntemi de bağımsız olarak değiştirilebilir

• Kullanıma dayalı faturalandırma ve uygulama içi satın alma

  • Aynı mutabakat süreci tüm kullanıma dayalı faturalandırma için geçerlidir
    • Sistem, aktif VM’ler ve disk kullanımıyla ilgili olguları kaydeder
    • Ölçüm worker’ı bunları ödeme sağlayıcısının durumuyla mutabık hale getirir
    • Yeni bir faturalandırma yöntemi eklense bile olgular aynen korunur; yalnızca her API ile mutabakat yöntemi değişir
  • iOS uygulaması da yalnızca birinin uygulama içi satın almayla abone olduğu olgusunu iletir; gerçek ödeme durumu daha sonra mutabık hale getirilir
  • Ödeme yapısı, diğer ekip üyelerinin de ele alabileceği bir alan haline gelmiştir; davet akışı gibi ürün özelliği değişikliklerinin faturalandırma sistemine zarar verme olasılığı da düşmüştür

[GN⁺]

Lobste.rs görüşleri

• Yazının özü olan değişiklikleri asenkron olarak tespit edip işleme yaklaşımı, bağlılığı azaltmak ve yan etkileri uygulamak için iyi
  Ancak LLM, kodun her yana dağılmasını engellemekten çok hızlandıran bir araç olduğu için mimari açıdan teknik borca dönüşmesi kolay. Anlama hızından daha hızlı üretilen kodun nasıl incelenebileceği de soru işareti; Exe’nin kod incelemesi bile yapmadığı kısmı ise daha da korkutucu

  • Zaten pek de ciddi olmayan teknoloji sektörünün şu anda özellikle ciddiyetsiz bir dönemden geçtiğini hatırlamak gerek
  • Faturalama sistemleriyle uğraşan biri olarak oldukça korkutucu bir yaklaşım. Faturalama platformu, birkaç sınırları net bağlamdan oluşur; LLM ise alan sınırlarını iyi koruyamadığı için büyük sıkıntı çıkarma ihtimali yüksek
  • “LLM kullansan da” değil, “özellikle LLM kullanırsan” kod daha da dağılmıyor mu diye düşündüm
  • O alıntının Orwell’e değil, Upton Sinclair’e ait olduğunu biliyorum

• Bu mimari ilginç olsa da, yazının başında ortaya konan sorunu nasıl çözdüğü belirsiz. Ödeme reddedildiğinde, tüm kaynakların ödenmesini garanti etmektense önce ödenmemiş kaynakların sağlanmasına yol açacak gibi görünüyor
  Faturalama çalışanı declined bilgisini yayımlayıp kaynakları geri çekebilir, ama bu temiz tek yönlü akışla kıyaslandığında döngüsel bir yapı olur. Exe gibi aylık faturalanan bir bilişim hizmeti için uygun olabilir, ancak fiziksel ekipman gönderen ya da başka bir hizmetin koltuklarını yeniden satan işletmeler için kabul etmesi zor bir ödünleşim

  • Ürün, soyut ve ikame edilebilir bir yazılım merkezli faturalama modeli. Kullanım bazlı faturalama, ücretlendirme olayı oluştuğunu gösteren analitik verilere dayanır ve faturalama sisteminin bunları toplayıp tutarlı bir fatura dökümü oluşturması daha iyidir. Ücretlendirme olayları birçok yerde oluşabileceği için bunu ürün kodunun dışına ayırmak da sağlıklıdır
    Yine de API çağrıları veya veritabanı işlemleri başarısız olduğunda, abonelik durumu anormal olduğunda ya da koltuk ödemesi reddedildiğinde bunun nasıl ele alındığına doğrudan yanıt vermiyor. Refactoring yüzünden analitik toplamanın bozulması, belirli bir satırın artık değişmiş olarak işaretlenmemesi ya da yeni bir yolda değişiklik işaretinin atlanması gibi sorunlar da aynen kalıyor
    Koltuklar, ücretsiz kullanım kotası sınırları, maksimum harcama limiti ayarı, ön ödemeli bakiyeden düşüm gibi ürün içinde bulunan faturalamayla ilgili durumları da çözmüyor. Ürün servisi olay yayımlayıp faturalama servisi uyum durumunu tekrar ürüne yansıtabilir, ama o zaman duruma sahip dağıtık sistemde iki aktör oluşur

• Stripe yalnızca tek bir sayı istiyor gibi görünse de, belli bir ölçekte ödemenin ayrıntılı kalemlerini de sağlamak takas ücretlerini düşürüp onay oranlarını artırabilir

• Exe’nin kod incelemesi yapmama yaklaşımı taze geliyor. Öyleyse sürümleme ve testleri nasıl yürüttüklerini merak ediyorum