Marketplace Hosting ve Altyapı

Marketplace hosting neden özel bir problemdir?

Bir marketplace, tek satıcılı bir mağazadan çok daha ağır bir yük profiline sahiptir: binlerce satıcının katalog güncellemesi, arama trafiği, kampanya anında oluşan ani yük (spike) ve çok satıcılı sepetin arka planda birden çok siparişe bölünmesi. Bu yüzden marketplace hosting üç şeyi aynı anda sağlamak zorundadır: yüksek trafik dayanımı, düşük gecikme ve yüksek erişilebilirlik (high availability). Orta ve büyük ölçekte bu üçlüyü en verimli karşılayan yapı; yönetilen (managed) bulut servisleri üzerine kurulu, otomatik ölçeklenen bir mimaridir.

Bulut sağlayıcı karşılaştırması

Aşağıdaki pazar payı değerleri sektör raporlarına dayalı kamuya açık ve temsili verilerdir; kesin oranlar çeyrekten çeyreğe değişir. Seçim tek bir tabloyla değil, ekibin uzmanlığı ve gerekli servislerle yapılmalıdır.

Referans mimari katmanları

Ölçeklenebilir bir marketplace altyapısı genellikle şu katmanlardan kurulur (AWS terminolojisiyle, diğer bulutlarda muadilleri vardır):

• Load Balancer (ALB): Sağlık kontrollü, HTTP/2 destekli trafik dağıtımı.
• Auto Scaling Group: CPU %70 üstünde ölçek büyütme, %30 altında küçültme; min/desired/max örnek sayısı.
• Yönetilen veritabanı (RDS, Multi-AZ): Otomatik yük devretme ve zamanlı yedekleme.
• Önbellek (ElastiCache/Redis): Oturum, katalog ve sık sorguların önbelleklenmesi.
• Nesne depolama (S3): Görsel ve statik dosyalar; sürümleme ve yaşam döngüsü kuralları.
• CDN (CloudFront): Kenar (edge) sunuculardan HTTPS ile hızlı içerik dağıtımı.
• DNS (Route 53): Alan adı ve CDN’e alias yönlendirme.

Bu mimarinin altyapı-olarak-kod (Terraform) ile tanımlanması; ortamların tekrar üretilebilir, denetlenebilir ve hızlı kurulabilir olmasını sağlar.

Ölçekleme ve kapasite planlaması

Kapasiteyi tahminle değil formülle belirleyin. Gerekli uygulama örneği sayısı:

örnek sayısı = ⌈ tavan eşzamanlı istek (RPS) ÷ örnek başına RPS kapasitesi ⌉ × 1,3

1,3 çarpanı ani yük ve bakım için ~%30 baş payı bırakır. Yüksek erişilebilirlik için minimum örnek sayısını 2’den az tutmayın; tek örnek, bakım veya arıza anında kesinti demektir. Auto-scaling politikalarını gerçek trafiğe göre kademeli tetikleyin ki maliyet ile performans dengesi korunsun.

Veritabanı optimizasyonu

Marketplace’lerde en sık darboğaz veritabanıdır. Uygulanacak sıra:

• İndeksleme: Sık filtrelenen kolonlarda kompozit indeks; kategori + fiyat gibi birlikte kullanılan alanlar tek indekste.
• Materialized view: Kategori istatistikleri gibi ağır toplu sorguları önceden hesaplayıp gece yenileyin.
• Read replica: Yazmayı ana sunucuda, okumayı çoğaltıcılarda çalıştırarak okuma yükünü dağıtın.
• Partitioning: Milyonlarca satırlık sipariş tablosunu aylık partition’lara bölerek sorguyu ilgili aralıkla sınırlayın.
• Connection pooling: PgBouncer ile on binlerce istemci bağlantısını yüz düzeyinde gerçek veritabanı bağlantısına indirin.

CDN ve çok katmanlı önbellek

Performansın büyük kısmı önbellekten gelir. Dört katmanı birlikte kurgulayın: tarayıcı önbelleği (statik varlıklara uzun Cache-Control), CDN kenar önbelleği, uygulama önbelleği (Redis) ve veritabanı sorgu önbelleği. Etkinliği tek bir metrikle izleyin:

önbellek isabet oranı = isabet ÷ (isabet + ıska) × 100

Sağlıklı bir katalog trafiğinde CDN ve Redis birlikte %80–90 isabet oranına ulaşabilir; bu, isteklerin büyük kısmının origin’e hiç gitmeden karşılandığı anlamına gelir. Ürün güncellendiğinde önbelleği tembel (lazy) yöntemle geçersiz kılın ve CDN yolunu da invalidate edin ki tutarsızlık oluşmasın. Next.js kullanan vitrinlerde ISR ile sayfaları belirli aralıkla yeniden üreterek hem hız hem tazelik sağlanır.

İzleme, SLA ve uptime bütçesi

İzlenmesi gereken çekirdek metrikler: p50/p95/p99 gecikme (hedef p95 < 200 ms), 5xx hata oranı (hedef < %0,1), saniyedeki istek (RPS), CPU/bellek kullanımı (hedef %60–80), veritabanı bağlantı havuzu ve yavaş sorgular, önbellek isabet oranı (hedef > %80) ve erişilebilirlik. Uptime hedefini somut kesinti bütçesine çevirin:

Uyarıları CPU, hata oranı ve gecikme eşiklerine bağlayın; kritik alarmları e-posta/SMS/Slack’e yönlendirin. APM araçları (New Relic, Datadog, X-Ray) fonksiyon süresi, sorgu ve dış API çağrılarını uçtan uca izler.

Maliyet: ölçeğe göre altyapı

Aşağıdaki değerler ölçeğe göre yaklaşık/temsili aralıklardır; gerçek fatura bölge, trafik profili ve mimariye göre değişir.

Tasarruf kaldıraçları: rezerve örnekler (~%30–60 indirim), spot örnekler (dev/test), gece ölçek küçültme, S3 yaşam döngüsüyle arşivleme ve CDN ile bant genişliği tasarrufu. Read replica eklemeden önce önbellek isabet oranını yükseltmek çoğu zaman daha ucuzdur.

Veri yerelleşmesi ve uyum

Marketplace’ler yoğun kişisel veri işler; bu nedenle KVKK 6698 kapsamında verinin nerede tutulduğu önemlidir. Kişisel verinin Türkiye veya AB bölgelerinde barındırılması, yedekleme ve loglama politikalarının KVKK ile uyumu ve ödeme akışında PCI DSS gereklilikleri altyapı kararının parçası olmalıdır. Uygulama ve entegrasyon katmanının kurulumu için marketplace sistemi, mobil erişim için mobil marketplace yazılarına; uçtan uca kurulum desteği için multi-vendor pazaryeri kurulumu çözümüne bakın. Altyapınızı birlikte planlamak isterseniz talebinizi iletin.