Bugün satılan “e-ticaret platformları”nın büyük çoğunluğu 2014’ün web’ine göre tasarlanmıştır. Tek bir vitrin, masaüstü bir ödeme akışı, birkaç saniyede bir gelen Stripe webhook’u ve afişleri çeyrekte iki kez güncelleyen bir pazarlama ekibi varsayarlar. Modern ticaret bunların hiçbirine benzemiyor — ve aksini varsayan ekipler bu gerçeği genelde Black Friday gecesi, saat 02:00’de, veritabanı CPU’su yüzde 100’e dayanmışken keşfediyor.
Bu yazı, 2025’te bir e-ticaret platformu kurarken (ya da yeniden kurarken) gerçekten önemli olan şeylerin pratik bir rehberidir. “Takip edilmesi gereken trendler” doldurması yok — yalnızca mağazanızın saatte 50 sipariş mi yoksa 5.000 sipariş mi taşıdığını belirleyen mimari kararlar.
Monolitler Modern Yük Altında Neden Çatlıyor
Klasik LAMP-stack veya Magento tarzı monolit, tahmin edilebilir biçimlerde çöker. Ürün sayfaları, sepet, ödeme, arama, yönetim paneli ve pazarlama CMS’i — hepsi tek bir veritabanını ve tek bir deploy sürecini paylaşır. Bir TikTok videosundan ana sayfaya trafik patlaması geldiğinde, sepetleri serileştiren aynı MySQL örneği boğulmaya başlar. Ödeme gecikmesi 200 ms’den 4 saniyeye çıkar. Dönüşüm yüzde 30 düşer. Yalnızca okuma yoğun parçaları ölçekleyemediğiniz için tüm monolitiniz dikey olarak büyütmek zorunda kalırsınız.
Daha derin sorun değişim hızıdır. Monolit; pazarlama, kategori yönetimi ve mühendislik ekiplerini aynı release treninde olmaya zorlar. Yeni bir ürün detay sayfasında A/B test mi yapmak istiyorsunuz? Ödeme işlemcisiyle aynı kod tabanına dokunuyorsunuz. Her değişikliğin etki alanı bütün işletmedir.
Eski sistemlerde sıkça gördüğümüz somut başarısızlık örüntüleri:
- Flash satış sırasında
SESSIONStablosunda kilit; çünkü ödeme yazımları okuma replikalarını bloklar - Tek bir SKU fiyat güncellemesinden sonra tam sayfa cache invalidation fırtınası
LIMIT’siz, indekssiz admin sorgularının vitrini yere sermesi- WooCommerce + WordPress kurulumlarının yaklaşık 200 eşzamanlı ödemede sert tavana toslaması
Tüm postmortem’leriniz “daha çok cache ekleyelim” diye bitiyorsa, sizin cache probleminiz yok. Mimari probleminiz var.
Headless Commerce: Aslında Ne Demek?
“Headless”, kime sorduğunuza göre altı farklı anlama gelen terimlerden biri. Dürüst tanımı: ticaret motorunuz (katalog, sepet, sipariş, ödeme, stok) API’ler sunar ve vitriniz bu API’leri tüketen ayrı bir uygulamadır. İkisi birbirinden bağımsız deploy edilir.
Kazanımlar:
- Frontend özgürlüğü: Next.js, Astro, SvelteKit — ekibinizin iyi yazdığı her şey
- Çok kanallı erişim: aynı API’ler web, mobil uygulama, mağaza içi kiosk ve pazaryeri entegrasyonlarını besler
- Bağımsız ölçekleme: vitrin uç noktası 100k RPS taşırken sepet servisi mütevazı sunucularda çalışabilir
- Daha hızlı deney: pazarlama, backend deploy’u beklemeden UI değişikliği yayınlar
Maliyeti — ki satıcıların atladığı kısım budur — entegrasyon işi ve operasyonel karmaşıklıktır. Artık bir frontend, bir BFF katmanı, bir arama servisi (Algolia veya Meilisearch), bir CMS (Sanity, Contentful, Storyblok) ve bunların arasındaki sözleşmeleri siz yönetiyorsunuz. Tipik bir Shopify Plus → headless geçişi, küçük bir ekiple 4-6 ay sürer ve ilk iki ayı eski monolitin size bedava verdiği özellikleri yeniden üretmekle geçirirsiniz: hediye kartları, indirim kombinasyonları, ülke bazlı vergi hesaplama, uluslararasılaştırılmış URL’ler.
Ne zaman değer? Kabaca: 5M USD+ GMV yaptığınızda, gerçek bir frontend ekibiniz olduğunda ve vitrininiz farklılaşamadığı için müşteri kaybettiğinizde. Bu eşiğin altında, iyi ayarlanmış bir temayla yönetilen platform genellikle doğru tercihtir.
Tiyatro Olmayan Yapay Zeka Kişiselleştirme
Birlikte alınma sıklığına dayanan “bunu alanlar şunu da aldı” widget’ları 2003’ten beri var. 2025’te yapay zeka kişiselleştirme dediğimiz şey bu değil. İlginç çalışma üç yerde oluyor:
- Semantik arama — ürün kataloğunu embedding’leyerek, kimse ürünü “yağışlı iklim” diye etiketlemese bile “yağışlı iklim için sıcak bir mont” sorgusunun doğru sonuçları döndürmesi
- Dinamik merchandising — kategori sayfalarını yalnızca geçmiş satın almalara değil, mevcut ziyaretin sinyallerine göre oturum bazında yeniden sıralamak
- LLM destekli destek ve keşif — kataloğu gerçekten anlayan konuşma tabanlı ürün bulucular
Mimari kritik. Her ürün sayfası render’ında senkron LLM çağrısı yapmak, 4 saniyelik TTFB ve 40 bin dolarlık OpenAI faturası almanın harika bir yoludur. Önerdiğimiz desen: embedding’leri geceleri önceden hesaplayın, LLM yanıtlarını sorgu düzeyinde agresif şekilde önbelleğe alın ve modeli yalnızca katkısının gecikmeye değdiği uç noktalarda kullanın.
Yapay zekanın iş dünyasını nasıl dönüştürdüğünü ayrıca yazdık — aynı ilkeler burada geçerli: ölçülebilir tek bir problemle başlayın, küçük bir modeli prod’a alın, kontrol grubuna karşı kazanımı ölçün, sonra genişletin.
Performans Dönüşümdür
Google’ın Core Web Vitals’ı bir SEO işareti değildir. Doğrudan bir dönüşüm kaldıracıdır ve veriler nettir: mobil ticarette LCP’deki her ek 100 ms, dönüşümün yaklaşık yüzde 1’ine mal olur. LCP’yi 2,5 saniyenin altına çekmek, 3,5 saniyelik bir başlangıç noktasına kıyasla genellikle ölçülebilir bir artış sağlar.
Modern bir vitrin için pazarlık edilemezler:
- Görseller: WebP yedekli AVIF, breakpoint başına boyutlandırılmış, fold altında lazy-load, layout shift’i engellemek için açık
width/height - CDN: tüm statik varlıklar ve önbelleklenebilir tüm HTML yanıtları edge’den — Cloudflare, Fastly veya doğru cache key’leriyle CloudFront
- JS bütçesi: kritik yolda 170 KB’tan az sıkıştırılmış JavaScript. Vitriniz 1,2 MB JavaScript gönderiyorsa, daha hızlı bir sunucuyla çözebileceğiniz bir performans probleminiz yok demektir
- Üçüncü taraf script’ler: çeyrekte bir denetleyin. Pazarlama ekibi yedi tag manager script’i ekler ve sitenin neden yavaş olduğunu merak eder
Mobilde hesap daha da acımasız — ticaret trafiğinin büyük çoğunluğu mobil ve mobil kullanıcıların çoğu istikrarsız bir 4G üzerinde orta seviye Android cihaz kullanıyor. Bu konuyu mobil uygulamaların gücü yazımızda derinleştirdik; özeti şu: “mobil öncelikli” bir tasarım sloganı değildir, JavaScript için bir bütçe ve tüm ekip için bir disiplindir.
Güvenlik ve PCI: Opsiyonel Değil, Glamurlu da Değil
Kart verisi işliyorsanız PCI-DSS sizin için geçerlidir. En ucuz yol kart verisi işlememektir: PAN’ın sunucunuza hiç değmemesi için Stripe Elements, iyzico’nun barındırılan formu veya muadili çözümler kullanın. Bu seçim sizi PCI-DSS Level 1’den (denetim ve üç ayda bir ASV taraması) SAQ A’ya (öz-değerlendirme anketi) düşürür. Tek bu mimari karar size yıllık altı haneli bir uyum faturasından tasarruf ettirebilir.
Ödemenin ötesinde, e-ticaretin tehdit yüzeyi yoğundur: müşteri girişlerinde credential stuffing, şifre sıfırlama akışları üzerinden hesap ele geçirme, fiyat verilerinin scraping’i, ödemede carding saldırıları, hediye kartı bakiyesi enumerasyonu ve ele geçirilmiş bir üçüncü taraf script’inden sızan Magecart tarzı skimmer’lar. Sıkı CSP, her harici script üzerinde subresource integrity, auth uç noktalarında rate limiting ve edge’de bot yönetimi artık temel gereksinimdir.
Daha geniş tabloyu güvenli web uygulamaları geliştirme yazımızda ele aldık. E-ticarete özel kuralımız şu: her müşteri girdisinin düşmanca olduğunu varsayın, her üçüncü taraf script’inin er ya da geç ele geçirileceğini varsayın ve etki alanını ona göre tasarlayın.
Ölçekte Sizi Mahcup Etmeyecek Altyapı
Mühendislik saatlerinin büyük kısmı ve lansman sonrası pişmanlıkların çoğu altyapı yığınında yaşar. Birkaç görüş:
Bulut, kolokasyon değil
Çok spesifik uyum nedenleriniz yoksa AWS, GCP veya Azure’u istersiniz. Ucuz oldukları için değil — değiller — yönetilen servislerin (RDS, ElastiCache, CloudFront, SQS) dört kişilik bir ekibe normalde on kişiyle yönetilecek altyapıyı işletme imkânı verdiği için. Hâlâ VPS-üzerinde-cPanel kurulumundaysanız, bulut göç rehberimiz pragmatik yolu anlatıyor.
Darboğaz her zaman veritabanıdır
Vitriniz web katmanında asla CPU-bound olmayacak. Veritabanı-bound olacak. Katalog sorguları için okuma replikaları, yazımlar için ayrı bir primary, PgBouncer veya RDS Proxy üzerinden connection pooling ve kategori ile arama sayfaları için agresif materialized view kullanımı. Veritabanı optimizasyonu üzerine ayrı bir yazımız var — ticaret için özeti şu: sıcak sorgularınızı indeksleyin, okumaların hâkim olduğu yerde denormalize edin ve bir admin sorgusunun vitrinle aynı connection pool’u paylaşmasına asla izin vermeyin.
Asenkron yapabildiğiniz her şey
Sipariş onay e-postaları, depoya stok senkronu, ERP güncellemeleri, pazarlama event stream’leri — bunların hiçbiri checkout istek yolunda olmamalı. SQS, Kafka veya iyi işlettiğiniz neyse oraya itip işçilere bırakın. 400 ms’de tamamlanan ve müşteriye 2 saniye sonra e-posta gönderen bir checkout, SendGrid’i beklediği için 3 saniye süren bir checkout’tan kesinlikle daha iyidir.
Gözlemlenebilirlik bir ürün özelliğidir
Funnel’in her adımında dönüşüm oranını, /api/cart’ın p95 latency’sini ve /checkout/complete üzerindeki hata oranını gerçek zamanlı olarak bilmeniz gerekir. Monitoring’iniz “sunucu ayakta” seviyesinde duruyorsa, hataları kızgın tweet’lerden öğrenirsiniz. Datadog, Grafana + Prometheus, Honeycomb — birini seçin ve yalnızca sistem metriklerini değil iş metriklerini de enstrümante edin.
Kurmaya Hazır mısınız?
Bir replatforming kararının karşısındaysanız — Shopify Plus’tan headless’a, WooCommerce’den ölçeklenen bir şeye veya sıfırdan bir D2C kuruluma — en kötü hamle teknolojiyle başlamaktır. Kısıtlarla başlayın: sipariş hacmi, ekip büyüklüğü, uluslararasılaştırma, kanal karışımı ve sizi gerçekten farklılaştıran iki üç müşteri deneyimi. Mimari bunlardan türetilir.
İstanbul, Körfez ve Avrupa’daki ekiplere, ilk Black Friday’lerini savaş odasına ihtiyaç duymadan atlatan ticaret platformları kurmalarında yardımcı olduk. Stack’iniz hakkında doğrudan bir sohbet istiyorsanız — satış konuşması değil — bizimle iletişime geçin. Yeniden kurmanız mı, refactor etmeniz mi, yoksa sadece bir CDN açıp çeyreği kapatmanız mı gerektiğini açıkça söyleyeceğiz.
