Bir pazar yeri platformuna dışarıdan bakınca her şey basit duruyor: ürün listesi, sepete ekle, ödeme yap, tamam (inanın bana). Ama işin aslı şu ki, o “tamam” anı tam da en karmaşık kısım. Çünkü burada tek bir kullanıcı tipi yok; alıcı var, satıcı var, stok var, güven var, yorum var… hepsi aynı anda dönüyor, hem de birbirini etkileyen bir şekilde. Hani Etsy, eBay ya da küçük ölçekli ikinci el platformları düşünün — yüzeyde sakin görünürler ama arkada bayağı gürültülü bir sistem çalışır, inanın.
Eh, Geçen sene İstanbul Maslak’ta bir girişim ekibiyle sohbet ederken tam da bu konu açılmıştı. Ürün kataloglarını büyütmek istiyorlardı ama stok senkronu yüzünden gece yarısı siparişler birbirine giriyordu. Açık konuşayım, mesele sadece “iyi bir veritabanı seçelim” kadar düz değil. Bazen mimarinin kendisi ürünü büyütüyor… bazen de sessizce çökertiyor. Bu kadar mı? Hayır, değil — ama oradan başlamak gerekiyor.
Evet, doğru duydunuz.
Pazar Yerinin Kalbi: Kim Ne Yapıyor?
Rolleri net ayırmak lazım. Alıcı kayıt olur, ürün arar, satın alır. Satıcı ürün ekler, stoğunu günceller, siparişleri görür. Sistem de bunların ortasında oturup her hareketi kayda alır; biraz hakem gibi, biraz da noter gibi davranır yani —. Çok daha hızlı karar vermek zorunda kalır.
Ben 2023’te kendi side projemde buna benzer bir yapı denemiştim. Ürün tarafını tek tabloda tutmaya çalışınca işler ilk haftalarda idare etti, filtreler çoğaldıkça veritabanı nefes nefese kaldı. Sonra arama katmanını ayırdık. Performans bir anda toparlandı. İşin ilginci şu: teknik olarak “ek bileşen” ekledik, yani teoride sistem daha ağırlaşmalıydı, ama kullanıcı tarafında tam tersi hissettirdi — daha hafif, daha akıcı.
Kullanıcı servisi tek başına yetmez
Kullanıcı servisi burada sadece giriş çıkış yapan bir kapı değil. Profil yönetimi, rol ayrımı, adres defteri, doğrulama süreçleri — hepsi onun üstüne biniyor, hem de zamanla. Bir platformda alıcıyla satıcının aynı kimlik havuzunda yaşaması mümkün; hatta pratikte çoğu zaman mantıklı da geliyor, ayrı tutmak bazen gereksiz karmaşa yaratıyor.
Gel gelelim, yetkilendirme kısmını hafife almak pahalıya patlayabiliyor. Ciddi. Satıcının yalnızca kendi ilanlarını düzenlemesi gerekirken başka ilanlara dokunabilmesi kötü haber demek — hem güven hem de hukuki açıdan. Bu yüzden kullanıcı servisinde sade ama sıkı bir model kurmak şart.
Katalog ayrı konuşur, sipariş ayrı
Ürün kataloğu ile sipariş sistemi aynı mantıkla çalışmaz. Katalog hızlı okunmak ister; sipariş ise sağlam yazılmak zorunda kalır. Yani katalog tarafında esnek veri modeli iş görürken sipariş tarafında ilişkisel düzen daha güven verir, daha öngörülebilir davranır.
Bunu mutfak benzetmesiyle düşünün. Katalog menü panosu gibi — hızlıca değişebilir, satıcı istediği zaman günceller (ki bu çoğu kişinin gözünden kaçıyor). Sipariş ise fiş defteri gibi; sonradan kafaya göre oynayamazsınız, oynarsanız muhasebe karışır.
| Bileşen | Ne işe yarıyor? | Neden önemli? |
|---|---|---|
| Kullanıcı Servisi | Kimlik ve profil yönetimi | Alıcı-satıcı ayrımını sağlar |
| Katalog Servisi | İlanlar ve metadata | Hızlı listeleme ve filtreleme verir |
| Sipariş Yönetimi | Siparişi oluşturur ve izler | Tutarlılık ve işlem sırası için kritik |
| Ödeme Servisi | Tahsilat yapar | Maddi güvenin merkezidir |
| Bildirim Servisi | E-posta/push/uyarı gönderir | Kullanıcıyı döngüde tutar |
Neden Tek Veritabanı Her Zaman Yetmiyor?
İlginç olan şu ki, Küçük startup’larda tek veritabanı cazip geliyor. Kurması kolay, operasyon yükü az, ekip rahat. Anlaşılır bir tercih. Ama pazar yeri büyümeye başlayınca ürün kartları şişiyor, aramalar ağırlaşıyor. Siparişler yoğunlaşınca tabloya kilit düşmeye başlıyor — işte tam orada can sıkıntısı başlıyor, hem de aniden.
Açık konuşayım, hibrit yaklaşım genelde daha gerçekçi duruyor: işlemsel veriler için ilişkisel veritabanı, ürün detayları için belge tabanı ya da esnek depolama alanı, arama için de Elasticsearch gibi bir motor. Bu üçlü yapı — ki bu tartışılır — kağıt üstünde biraz uğraştırıyor ama pratikte elinizi rahatlatıyor. Baya rahatlatıyor.
Pazar yerinde hız ile tutarlılık arasında ince bir ip var; biri fazla baskın olursa öbürü bozuluyor.
Sistem tasarımında sihir yok aslında — doğru yerde doğru araç kullanma meselesi var.
Nerede hangi depo mantıklı?
Siparişler için ilişkisel yapı hâlâ çok sağlam duruyor çünkü ödeme akışı yarıda bölünmeyi sevmiyor (şaşırtıcı ama gerçek). Ödeme alındı mı? Stok düştü mü? Sipariş iptal oldu mu? Bunlar birbirine bağlı sorular —. Cevabı temiz, tutarlı vermek lazım, yoksa geri dönmesi zor bir kaos başlıyor.
İşte tam da bu noktada devreye giriyor. MCP Patladı: 97 Milyon İndirimin Arkasındaki Hikâye yazımızda bu konuya da değinmiştik.
Doğrusu, Buna karşılık ürün açıklamaları bazen çok değişken oluyor; satıcının biri kısa yazıyor, biri uzun yazıyor, biri renk seçeneklerini uç uca dikiyor, biri video ekliyor… O yüzden katı şema yerine esnek model burada hayat kurtarıyor. Gerçekten. Daha fazla bilgi için EU uyumu API’ye döküldü: Law4Devs ne vaat ediyor? yazımıza bakabilirsiniz.
- İlişkisel veritabanı: Sipariş, ödeme ve stok gibi hassas alanlarda iyi iş çıkarır. — ciddi fark yaratıyor
- Belge deposu: Ürün metadata’sında rahatlık verir.
- Ayrılmış arama indeksi: Filtreleme ve sıralamada nefes aldırır.
- Nakil katmanı / kuyruk: Bildirimler ve arka plan işleri için işi yumuşatır.
Siparişte En Can Sıkıcı An: Yarış Durumu
Asıl belalı nokta burası. Diyelim ki son kalan ürünü iki kişi aynı anda satın almaya bastı. Birincisi başarılı olursa ikincinin de başarılı görünmesi tam anlamıyla felaket. Bu tür yarış durumlarını ilk kez Ankara’da bir fintech demosunda gördüğümde — nasıl desem — gözümün önünde ter akmıştı diyebilirim; sistem kağıt üzerinde sağlamdı ama test ortamında iki istek aynı anda gelince stok iki kez düşüyordu, ikisi de “sipariş tamam” diyordu. Korkunç.
Aslında — dur bir saniye — önce şunu söyleyeyim: bu sorun sadece teknik değil. Müşteri güvenini doğrudan vuruyor. Bir kere yaşandı mı geri toplaması zor. Özür e-postası göndermek işe yaramıyor çoğu zaman.
Çözüm tarafında birkaç yol var. Kilit mekanizmalarıyla atomik güncelleme yapmak en klasik yöntemlerden biri; database seviyesinde kilit kullanırsınız ya da iyimser kilitleme ile sürüm numarası takip edersiniz. Bence küçük ekiplerde sürüm numarası yaklaşımı daha anlaşılır oluyor çünkü debug etmesi nispeten kolay, ne olduğunu izlemek mümkün. Ama büyük ölçekte bazen yeterli olmuyor — o zaman rezervasyon süresi devreye giriyor.
Siparişi tamamlamadan önce ürünü örneğin 5 dakika boyunca askıya almak baya işe yarıyor. Kart sepetinde bekleyen müşteriye biraz zaman tanıyorsunuz. Ha bu arada bu yaklaşımın eksisi de var: terk edilen sepetleri temizlemek için ekstra background job gerekiyor. Yani çözüm bedava değil; sadece maliyet başka yere taşınıyor. Böyle işler. Bu konuyla ilgili Next.js’te Yorum Eklemenin En Temiz Yolu: App ve Pages yazımıza da göz atmanızı tavsiye ederim.
// Basitleştirilmiş stok rezervasyon akışı
BEGIN TRANSACTION;
IF stock_count > 0 THEN
stock_count = stock_count — 1;
reservation_expires_at = NOW() + INTERVAL '5 minutes';
CREATE ORDER(status='pending_payment');
COMMIT;
ELSE
ROLLBACK;
END IF;Bildirim Azsa Platform Soğuk Kalır
Bir de şu var. Pazaryerleri yalnızca işlem yapan makineler değil; ilişki kuran yapılar. Dağıtılan bildirimler olmazsa kullanıcı kendini boşlukta hissediyor. Siparişim onaylandı mı? Satıcı mesaj attı mı? Yorumum yayınlandı mı? Bunların cevabı gecikirse platform soğuk görünüyor — biraz tenha bir restoran gibi aslında, yemek iyi de atmosfer yok.
Şimdi gelelim işin can alıcı noktasına.
Kendi deneyimimden konuşuyorum, Geçen ay Kadıköy’de test ettiğim küçük bir satış uygulamasında bunu net gördüm. E-posta bildirimi vardı ama push yoktu. Kullanıcılar telefonu açıp tekrar tekrar kontrol ediyordu. Kağıt üstünde sorun yok gibiydi fakat pratikte hayal kırıklığı yaratıyordu — çünkü beklenti yönetimi bozuktu, bilgi boşluğu anksiyete yaratıyordu.
Şimdi, kendi deneyimimden konuşuyorum, Bildirimin yanında yorum sistemi de önemli. Puanlama sistemi sadece vitrin süsü değil, algoritmanın nasıl sıralama yaptığına bile etki ediyor. Yüksek puan alan satıcının görünürlüğü artınca satış döngüsü hızlanıyor. Ama sahte yorum riskini unutmayalım — burada da denge gerekiyor. Fazla serbest bırakırsanız spam çıkar, fazla sıkarsanız canlılık gider. İkisi arasında gidip gelinmek kaçınılmaz. Windows’ta Modern Standby Neden Kapatılır? Pil Gerçeği yazımızda da bu konuya değinmiştik. APP Plakalarda Yeni Dönem: Ücretsiz Değişim Ne Getiriyor? yazımızda da bu konuya değinmiştik.
Güven nasıl kuruluyor?
Puanlama sistemi biraz mahalle bakkalı mantığına benziyor aslında. Müşteri kime güveneceğini görmek istiyor; platform ne kadar iyi tasarlanmış olursa olsun “bu satıcının işi düzgün mü?” sorusu kalıyor zihinlerde. Sonuca baktığınızda review sistemi hem kalite sinyali hem de sosyal kanıt sağlıyor. Tek başına mucize değil ama eksikse fark ediliyor. Evet, bayağı fark ediliyor.
Küçük Startup ile Kurumsal Ölçek Aynı Şey Değil
Bakın şimdi. Küçük bir startup için en doğru karar çoğu zaman sadelik oluyor. Tek repo, takılmadan ilerleyen birkaç servis ve minimum operasyon yükü yeterli olabilir. Ekip üç kişiyse dağıtık mimariyi abartmanın pek lüzumu yok açıkçası — en büyük hata sırf “ileri teknoloji” diye gereksiz karmaşa kurmak (ki bu çoğu kişinin gözünden kaçıyor). Bunu yapan ekipler gördüm; altı ayda kendi sistemlerini anlayamaz hale geldiler.
Şunu söyleyeyim, Kurumsal tarafta ise hikâye değişiyor. On binlerce ürün, saatlik yoğun trafik, kampanya patlamaları, taksit entegrasyonları, kargo servisleri derken yapı doğal olarak parçalanıyor. Orada gözlemlediğim şey şu oldu: büyük şirketler çoğu zaman hızdan çok kontrollü büyümeyi seviyor (inanın bana). Bu bazen sıkıcı geliyor, “neden bu kadar yavaş?” diye soruyorsunuz, ama bütçeyi koruyor.
E tabi, geliştirici açısından bakınca modülerlik huzur getiriyor. Servis sınırı belli olunca hata izole kalabiliyor. Ama fazla mikroservis parçalayıcı da olabiliyor. Bir ara bunu yaşayan ekiplerden biri bana “siparişi tamamlamak yerine servis haritasını çiziyoruz” diye dert yanmıştı. Gülmüştük ama acıklıydı gerçekten.
Neye dikkat etmeli?
- Eğer trafik düşükse monolit + temiz modüller yeterli olabilir. (bu kritik)
- Trafik artıyorsa katalog ve aramayı ayırmak ilk iyi adım olur.
- Sipariş/ödeme hattını ayrı korumak veri kaybını azaltır.
- Bildirimleri kuyrukla yürütmek sistem nefesini açar.
Kendi Gözümden Çıkardığım Dersler
Bence, Neyse, uzatmayalım. Pazar yeri tasarımında en büyük tuzak insanın ilk bakışta her şeyi aynı kefeye koyması. Fakat katalog başka ritimde çalışıyor, sipariş başka ritimde, bildirim apayrı. Neticede iyi mimari dediğimiz şey aslında farklı ritimleri uyumlu çaldırabilmek — bunu yapamadığım projelerde hep şu oldu: yavaşlayan sorgular, kayan stoklar, giderek kızaran log ekranları. Tanıdık geliyorsa yalnız değilsiniz.
Dürüst olayım, bazen en fena olmayan görünen çözüm en kullanışsız olan çıkabiliyor. Mesela her şeyi event-driven yapmak güzel slogan. Ama ekip buna hazır değilse sonuç karmaşa oluyor, hata ayıklamak kâbusa dönüyor. O yüzden teknoloji seçerken moda değil bağlam önemli. Hatta bazen eski usul transaction + queue ikilisi fazlasıyla iş görüyor. Sıkıcı mı? Belki. Ama çalışıyor.
Yanlış rezervasyonu iptal etmek,
yanlış bildirimi silmek,
yanlış ödemeyi telafi etmek…
Hepsi gerçek dünyada karşınıza çıkar.
Her şey ilk denemede kusursuz gitmiyor maalesef.
Sıkça Sorulan Sorular
Pazar yeri platformunda en can alıcı bileşen hangisi?
-+ html code issue could be ignored maybe not ideal
Pazar yeri platformunda en kritik bileşen hangisi?
Cevap kısa:sipariş-stok-ödeme üçlüsü.En ufak kopukluk doğrudan para kaybına yol açar.O yüzden bu hattın tutarlı olması diğer neredeyse tüm özelliklerden önce gelir.
Mikroservis mi monolit mi daha iyi?
Eğer ekip küçükse monolit daha rahat olabilir.Büyüdükçe servisleri ayırmak mantıklı hale gelir.Ama sırf trend diye mikroservise geçmek çoğu zaman gereksiz yük getirir.
Aynı ürünü iki kişi alınca ne yapılmalı?
Daten atomic check-and-decrement gerekir.Rezervasyon süresi veya optimistik kilitleme overselling’i engeller.Bu bölüm özellikle yüksek trafikte çok önemli.
Bildirimin marketplace’te rolü nedir?
Bildirimin görevi kullanıcıyı döngünün içinde tutmaktır.Sipariş güncellemesi,yeni mesaj,yorum onayı gibi konularda gecikme olursa deneyim soğur.
Kaynaklar ve İleri Okuma”)
PostgreSQL Resmi Dokümantasyonu
AWS Well-Architected Reliability Pillar
Microsoft Azure Architecture Center
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
