Pontefy: Çok Satıcılı E-Ticaret Platformu

Platform ne yapıyor?

Platform, ticaret yaşam döngüsünün tamamını uçtan uca kapsıyor: zengin öznitelik tanımlamalarıyla ürün ve kategori yönetimi, depolar arası stok takibi, sepetten teslimata sipariş ve kargo süreci, müşteri ve kampanya yönetimi ve satıcılara ayrılmış paneller. Entegre ödeme ve abonelik modülleri de bunun yanında çalışıyor; yani yinelenen ticaret sonradan eklenen bir parça değil, aynı sistemin bir parçası.

Mimari yatay ölçekleniyor, ön yüz katmanı ise özelleştirilebilir. Yüksek trafikli senaryolarda bile hızlı pazara çıkışı mümkün kılan şey bu ikisi: vitrin, altındaki ticaret çekirdeği çatallanmadan markaya göre şekillendirilebiliyor.

Yetenekler

Pontefy geliştirme aşamasında. Aşağıdaki liste hedeflediğimiz yetenekleri anlatır; bitmiş bir ürünü değil, tasarımı tarif eder.

• Çok satıcılı destek — satıcıya özel paneller ve onboarding akışları
• Ürün ve kategori yönetimi — zengin öznitelik tanımlamaları
• Stok takibi — depolar arası gerçek zamanlı stok
• Sipariş ve kargo yaşam döngüsü — sepetten teslimata, kargo entegrasyonlarıyla
• Müşteri ve kampanya yönetimi — hedefli promosyonlar ve sadakat programları
• Entegre ödeme ve abonelik — yinelenen ticaret için
• Özelleştirilebilir vitrin — esnek ön yüz mimarisi üzerinde
• B2C, B2B ve marketplace modelleri tek platformdan

Nasıl inşa edildi?

• Yatay ölçeklenmek üzere kurgulanmış .NET mikroservis backend
• Read replica desteğiyle PostgreSQL işlemsel veritabanı
• API-first mimari; headless commerce birinci sınıf bir senaryo
• Yüksek hacimli operasyon için olay tabanlı sipariş işleme

Tek model üzerinde üç iş modeli, farkları veriye taşımak demek

B2C, B2B ve marketplace ancak aralarında değişen şeyler kodda dallanma değil veri olduğu sürece tek bir sistemin konfigürasyonu olarak kalabiliyor. Bunun yürüyüp yürümeyeceğine karar veren yer fiyatlandırma. Fiyat diye bir kolon yok: fiyat bir bağlam üzerinden çözümleniyor — müşteri ya da müşteri grubu, sözleşme, miktar kırılımı, para birimi, vergi yaklaşımı. Böylece bir B2B sözleşme fiyatı ile bir B2C liste fiyatı, girdileri farklı olan aynı çözümleme oluyor ve hiçbiri diğerinin özel hâli değil. Vergi gösterimi de aynı kurala tabi: fiyatların dahil mi hariç mi gösterileceği vitrinin değil bağlamın özelliği. Aynı kataloğun iki ayrı katalog olmadan hem tüketici mağazasına hem kurumsal hesaba hizmet edebilmesinin sebebi bu.

Stok bir sayaç değil, bir defter

Stok, azaltılan bir sayı olarak değil hareketler ve rezervasyonlar olarak tutuluyor. Sepette bekletme, verilmiş sipariş, depolar arası transfer ve iade; aynı fiziksel miktar üzerindeki dört farklı hak talebi ve tek bir sayaç bunları ne temsil edebiliyor ne de neden o değerde olduğunu açıklayabiliyor. Satılabilir miktar türetiliyor: eldeki miktardan açık rezervasyonlar düşülüyor. Rezervasyonların bir süresi var; terk edilmiş sepetlerin satılabilir stoğu sessizce tüketmesini engelleyen de bu.

Fazla satış bir yarış durumu ve yarışlar yazmanın gerçekleştiği yerde çözülmek zorunda. Rezervasyon, bir değeri okuyup sonra yazan uygulama kodunda değil; çakışan durumu başarısız kılan kısıtla birlikte veritabanında alınıyor. Önce-oku-sonra-yaz sürümü testte doğru çalışır ve tam da platformun kurulduğu trafik altında yanlış çalışır.

Sipariş yaşam döngüsü, kontrol etmediği sistemler üzerinde bir durum makinesi

Ödeme otorizasyonu, depo hazırlığı ve kargoya teslim; üçü de dışsal ve üçü de asenkron. Bu yüzden sipariş kendi durumunu tutuyor ve onlarınkiyle mutabakat kuruyor; herhangi birine yapılan bir çağrıyı doğrunun kaynağı saymıyor. Kısmi gönderim, siparişin altında satır grupları bazında sevkiyatları olan bir üst kayıt olmasının sebebi — ve bu yapı bir kez var olunca, üç satıcıya bölünen bir marketplace siparişi ile iki depodan çıkan bir B2C siparişi yapısal olarak aynı şey oluyor. Marketplace’in ayrı bir sipariş sistemine ihtiyaç duymamasının somut nedeni bu: bölünme, satıcılarla hiç ilgisi olmayan bir gerekçeyle zaten modeldeydi.

Satıcı panelleri de aynı karardan çıkıyor. Satıcı, senkron tutulması gereken kendi mağazasına sahip ayrı bir uygulama değil; ortak katalog ve kendisine ait sipariş satırları üzerinde kapsamlandırılmış bir görünüm alıyor.

Transaction bilinçli olarak küçük tutuluyor

Sipariş verme iki şeyi kaydediyor: rezervasyon ve siparişin kendisi. Geri kalan her şey — stok hareketinin işlenmesi, onay bildirimleri, faturalama, marketplace siparişinde satıcı bildirimi — ortaya çıkan olayın tüketicisi. Alternatifi, yani bir ödeme çağrısı ile bir kargo API’si boyunca veritabanı transaction’ını açık tutmak, ödeme adımının erişilebilirliğini bütün dış sistemlerin erişilebilirliğinin çarpımı hâline getirir; yavaşlayan bir kargo uç noktası mağazayı durdurur.

Olay, siparişle aynı transaction’da yazılıyor ve oradan dağıtılıyor; böylece commit’in hemen ardından ölen bir süreç bile sonraki işleri üretmiş oluyor. Tüketiciler idempotent, çünkü aynı olayı birden fazla kez görecekler; bu, düzenin bedeli ve alternatifinden ucuz.

Okuma ve yazma yolları global olarak değil sorgu bazında ayrılıyor

Katalog gezinmesi ezici çoğunlukla okuma trafiği ve bir an öncesine ait veriye tahammül ediyor. Ödeme adımı etmiyor: paraya ya da stoğa karar veren her şey primary’den okuyor. Bu yüzden replica kararı bağlantı seviyesinde sessizce uygulanan bir ayar değil, sorgu bazında ve açıkça verilen bir karar — aksi hâlde bir stok kontrolü replica’ya düşer ve aynı ürün iki kez satılır. Hangi okumaların bayat olabileceği konusunda açık olmak, read replica’yı aralıklı ve tekrar üretilemeyen hataların kaynağı olmaktan çıkarıp bir ölçekleme aracı yapan şey.

Headless, kuralların sunucuda kalması demek

Markaya özel vitrinler platformun çatallanmış kopyaları değil, aynı ticaret API’sine bakan ayrı ön yüzler. Bir vitrinin markaya göre şekillenirken çekirdeğin kurulum başına ayrışmamasını sağlayan bu. Beraberinde gelen kısıt ise şu: kampanya ve promosyon hesabı sunucu tarafında kalıyor. Tarayıcıda hesaplanan bir indirim, müşterinin seçebileceği bir indirimdir; vitrin fiyatın ne olduğunu soruyor ve cevabı gösteriyor — hiçbir zaman kendisi türetmiyor.