Toplu API Faturalamada Satır Bazlı Rezervasyon Deseni
Toplu GSTIN doğrulama endpoint'inde bazı satırların ücretsiz çıkması, tek seferlik bakiye kontrolünün neden yetersiz kaldığını ve satır bazlı atomik rezervasyonun çözümünü anlatıyor.
GSTExtract adlı tek kişilik GST SaaS'ında geliştirici, fatura başına çalışan rezerve-et/kapat/iade-et modelini toplu doğrulama endpoint'ine taşırken ciddi bir tasarım sorunuyla karşılaşıyor. Bir grup GST numarasında bazı satırlar önbellekten geliyor, bazıları bulunamıyor, bazıları format hatası veriyor ve bunların hepsi ücretsiz; hangi satırın gerçekten ücretli API çağrısı gerektirdiği ancak iş yapıldıktan sonra belli oluyor. Bakiyeyi baştan okuyup toplu ücretlendirme yapan yaklaşım, eşzamanlı isteklerde bakiyenin fazla satılmasına (overselling) yol açıyor.
Çözüm, tek kredi rezervasyonunu her satır için ayrı ayrı uygulamak: satır başına atomik bir koşullu UPDATE ile kredi rezerve ediliyor, sonuç bulunursa rezervasyon kalıcı oluyor, bulunamazsa iade ediliyor. Rezervasyon başarısız olursa o satır için ücretli API hiç çağrılmıyor, böylece ödenmemiş satırlar için gerçek para harcanmıyor. Yazar ayrıca rezervasyon işlemlerini worker thread'e taşıyınca SQLite bağlantı hatası aldığını, çözümün veritabanı yazımlarını event loop üzerinde tutup yalnızca HTTP çağrısını thread'e devretmek olduğunu anlatıyor.
Yazı ayrıca dışa aktarılan Excel dosyalarında formül enjeksiyonu riskine değiniyor: kayıt değerleri '=', '+', '-' veya '@' ile başlıyorsa başına tek tırnak eklenerek canlı formül çalıştırılması engelleniyor. Genel çıkarım, toplu faturalamanın aslında üç ayrı sorunun (bilinmeyen miktar, kısmi ücretsizlik, eşzamanlılık) tek bir çatı altında birleşmesi olduğu; satır bazlı rezervasyonun bu üçünü tek bir atomik ilkeye indirgediği.