Dropshipping mağazası açan çoğu kişi kısa yolların peşindedir. Kazanan ürünleri bulmak için forumlarda gezinirler, ucuz sanal asistanlar tutarlar ve algoritmanın bir gecede zenginlik getirmesini umarlar. Bu bana hiçbir zaman cazip gelmedi. Dropshipping'i bir mühendislik problemi olarak gördüm. Hızlı para peşinde koşmuyordum. Envanter senkronizasyonunu çözmek, gerçek piyasa değişikliklerine tepki veren fiyatlandırma algoritmaları oluşturmak ve akıl sağlığımı yitirmeden tedarikçi API'ları ile boğuşmak istiyordum. Mağaza, Node.js ve PostgreSQL kullanarak inşa ettiğim sistemin bir yan etkisi haline geldi.
Mağazaya Bir Backend Servisi Gibi Davranın
Dropshipping'i bir pazarlama işi olarak görmeyi bırakıp bir dağıtık sistemler zorluğu olarak ele almaya başladığınız an, problemler ilginçleşir. Üç farklı tedarikçi stokunuzu kontrol ederken bir vitrini nasıl güncel tutarsınız? Aynı tedarikçiler size haber vermeden maliyetleri değiştirdiğinde nasıl rekabetçi fiyatlandırma yaparsınız? Katalog elli SKU'dan beş bine çıktığında, tabloların içinde boğulmadan bunu nasıl yönetirsiniz?
Bu soruları yanıtlamak için bir boru hattı (pipeline) kurdum. Node.js, olay güdümlü (event-driven) mimariyi yönetti; çünkü aynı anda birden fazla tedarikçi bağlantısını idare etmek için bloklamayan (non-blocking) I/O'ya ihtiyacım vardı. PostgreSQL ise katı bir doğruluk kaynağı (source of truth) görevi gördü. Şema tasarımına büyük önem verdim çünkü özensiz bir envanter tablosu, var olmayan bir ürünü ilk kez fazla sattığınızda bir kabusa dönüşür.
Boru Hattını Oluşturmak
Temel görev basitçe ifade edilebilir: ürün verilerini tedarikçi API'larından çekmek. Uygulamada bu; SKU'ları, açıklamaları, görselleri, stok seviyelerini ve fiyatlandırmayı, birbirleriyle konuşmak üzere tasarlanmamış uç noktalardan (endpoints) almak anlamına geliyordu. Node.js ile tedarikçi akışlarına farklı aralıklarla erişen sorgulama (polling) servisleri yazdım. Gelen her veri paketi (payload), dahili mağaza veritabanımıza dokunmadan önce doğrulama ve eşleme katmanlarından geçti.
PostgreSQL'i ürünler, varyantlar, fiyat geçmişi ve senkronizasyon günlükleri için ayrı tablolarla yapılandırdım. Bir tedarikçi bir alan adını sessizce değiştirdiğinde veya bir sayı yerine null gönderdiğinde, boru hattı bunu yakaladı ve mağaza verilerini bozmak yerine bir hata kaydı oluşturdu. Bir günlük satırına bakıp hangi uç noktanın bozulduğunu, ne zaman gerçekleştiğini ve hangi alanların hatalı olduğunu tam olarak görebiliyordum. Bir tedarikçi hafta sonu API'sını "güncellemeye" karar verdiğinde, bu gözlemlenebilirlik (observability) beni birden fazla kez kurtardı.
Neler İyi Çalıştı
Otomasyon muazzam miktarda zaman kazandırdı. Başlarda manuel yaklaşımı denedim: tedarikçi tablolarını indirmek, onları elle temizlemek, görselleri formatlamak ve CSV'leri mağazaya yüklemek. Katalog birkaç düzineden fazla ürüne ulaştığında bu imkansız hale geldi. Otomatik boru hattı; yeni listelemeleri, fiyat güncellemelerini ve stok ayarlamalarını, bir tabloya bir daha dokunmama gerek kalmadan halletti.
Ürün açıklamalarını ölçeklendirmek şablonlar aracılığıyla gerçekleşti. Neredeyse özdeş beş yüz ürün için benzersiz metinler yazmak sürdürülebilir değildir. Bunun yerine, malzeme, boyut veya renk gibi tedarikçi niteliklerini alan ve bunları yapılandırılmış açıklama bloklarına enjekte eden bir şablon katmanı oluşturdum. Çıktı, dönüşüm için yeterince temiz ve binlerce yeni SKU eklerken manuel metin yazarlığı gerektirmeyecek kadar tutarlıydı.
Fiyat takibi de beklentilerimi aştı. Temel ürünlerin bir alt kümesi üzerinde rakip fiyatlarını takip eden hafif bir izleme katmanı oluşturdum. Değişimleri tespit ettiğinde sistem, yapılandırdığım koruma sınırları (guardrails) dahilinde marjlarımızı otomatik olarak ayarladı. Eğer bir tedarikçi toptan maliyeti düşürürse, listeleme fiyatı bu değişikliği günler yerine dakikalar içinde yansıtabiliyordu. Bu duyarlılık, düşük marjlı ürünlerde fark edilir bir fark yarattı.
Neler Bozuldu ve Neden
Tedarikçi API'ları tutarlılıktan yoksundur. Bu bir şikayet değil; jeolojik bir gerçektir. Bir ortak, öngörülebilir sayfalama (pagination) ile temiz JSON sunar. Bir diğeri, Pazartesi günü camelCase etiketli XML, Çarşamba günü ise snake_case döndürür. Hız sınırları (rate limits) cömertten cezalandırıcıya kadar değişir. Kesinti süreleri, uygun durum kodları yerine HTML hata sayfaları aracılığıyla iletilir. Sonuçta, 2003 yılında tasarlanmış gibi davranan uç noktalar için savunmacı ayrıştırıcılar (defensive parsers) ve yeniden deneme mantığı (retry logic) yazmak zorunda kalırsınız.
Envanter senkronizasyonunda uykularımı kaçıran yarış durumları (race conditions) vardı. Şöyle hayal edin: iki müşteri, saniyeler arayla son birimi sipariş ediyor ya da bir tedarikçi webhook'u, bir alıcı ödeme adımına tıkladığı anda stokun sıfıra indiğini söylüyor. İlk başta kullandığım "önce oku, sonra güncelle" mantığı felaketle sonuçlandı. Senkronizasyon katmanını, yüksek hızlı SKU'lar için atomik PostgreSQL işlemleri ve karamsar kilitleme (pessimistic locking) kullanarak yeniden yazmak zorunda kaldım. Bu, işin içinde gerçek paranın olduğu bir durumda hiçbir eğitimin sizi tam olarak hazırlayamayacağı, eşzamanlılık (concurrency) konusunda acı verici ve pratik bir dersti.
En büyük hatam, müşteri destek otomasyonunu ihmal etmekti. Veri boru hatlarına takıntılı hale gelmiştim ve işin insani boyutunu sonradan akla gelen bir detay gibi görmüştüm. Siparişler geç geldi. Tedarikçiler yanlış rengi gönderdi. Ben API zaman aşımı hatalarını ayıklarken, müşterilerin gönderdiği e-postalar saatlerce gelen kutumda bekledi. Destek talebi yönlendirmem, otomatik yanıtlarım veya chatbot devretme mekanizmalarım yoktu. Teknik altyapı sağlamdı. Ancak insani altyapı eksikti ve bu boşluk işe, istikrarsız bir webhook'tan çok daha fazla zarar verdi.
Bir Mühendis Gibi Görselleri Test Etmek
Ürün görselleri üzerinde yan bir deney yürüttüm. Oturum tabanlı gruplandırmaya bağlı basit URL parametresi yönlendirmesi kullanarak farklı kullanıcılara farklı ana görseller (hero images) sundum. Bir varyant ürünü sade beyaz bir arka planda gösteriyordu. Diğeri ise gerçek bir masa üzerinde, yaşam tarzı (lifestyle) ortamında sunuyordu. Her bir grup için dönüşüm oranlarını, doğrudan sipariş akışına bağlı temel olay günlüğü (event logging) kullanarak takip ettim.
Küçük değişiklikler etkileşimi artırdı. Yaşam tarzı çekimleri her zaman kazanmadı ama kazandığında, sağladığı artış önceliklendirme biçimimi değiştirecek kadar anlamlıydı.