E-Ticaret Hosting Seçimi: Satış Kaybetmeyen Altyapı

Bir kurumsal site bir saat kapalı kalırsa itibar kaybedersiniz; bir mağaza bir saat kapalı kalırsa o saatin cirosunu ve sepetini terk eden müşteriyi kaybedersiniz. E-ticaret hosting seçimi bu yüzden “en ucuz paket” sorusu değil, “kampanya gününde ayakta kalır mı, ödeme adımı güvenli mi, yedekten kaç dakikada dönerim” sorusudur.

Bu yazıda mağazanın hostingden beklediği beş şeyi, platforma göre değişen ihtiyaçları, kampanya trafiği için kaynak planlamasını, güvenlik ve uyumluluk gereklerini ve ölçeğe göre karar tablosunu anlatıyoruz. LIONFIN kurumsal hosting paketleri yüksek kaynak, SLA ve öncelikli destekle e-ticaret için tasarlanmıştır; daha büyük ölçekte VDS sunucu seçeneği devreye girer.

Mağazanın hostingden beklediği 5 şey

1. Öngörülebilir performans: Ürün listeleme, filtreleme ve sepet işlemleri her istekte veritabanına yük bindirir; NVMe disk, yeterli RAM ve Redis nesne önbelleği olmadan sayfa süresi trafikle birlikte artar.
2. Eş zamanlı kullanıcı kapasitesi: Kampanya duyurusundan sonraki ilk 10 dakikada gelen yük, normal günün on katına çıkabilir. Eş zamanlı PHP işlem sayısı ve CPU payı bu anı belirler.
3. Güvenli ödeme akışı: Sitenin tamamı HTTPS, güncel TLS ve güvenlik duvarı arkasında olmalı; ödeme sayfası üçüncü taraf sanal POS’ta bile olsa sepet ve adres formu sizin sunucunuzdadır.
4. Hızlı geri dönüş: Günlük yedek yetmez; sipariş tablosu için saatlik ya da anlık yedek ve dakikalar içinde geri yükleme gerekir.
5. Ulaşılabilir destek: Gece 02.00’de ödeme bildirimi gelmiyorsa yanıt veren biri olmalı; SLA’lı destek e-ticarette lüks değildir.

Uptime ve SLA kavramlarının sözleşmede nasıl yer alması gerektiği hosting uptime ve SLA nedir yazısında açıklanır.

Platforma göre ihtiyaç: WooCommerce, OpenCart, PrestaShop, özel yazılım

Altyapı kararını platformla birlikte verin. WordPress tabanlı mağazalar için ölçütler WordPress hosting seçimi yazısında, işletim sistemi kararı Linux hosting mi Windows hosting mi yazısında ayrıntılıdır.

Kaynak planlaması: kampanya günleri için

Kaynağı ortalama güne değil, en yoğun saate göre planlayın. Yaklaşım şöyle:

1. Mevcut veriyi okuyun: Analitik aracında son üç ayın en yoğun saatindeki eş zamanlı kullanıcı sayısını ve panelin kaynak kullanım grafiğinde o saatteki CPU/RAM tepe değerini bulun.
2. Kampanya çarpanı belirleyin: Kampanya ve bayram dönemlerinde tepe trafiğin kaç katına çıktığını geçmiş verilerden tahmin edin.
3. Eş zamanlı işlem sayısına çevirin: Önbellek dışı sayfa isteği (sepet, ödeme, hesap) sayısı, gereken eş zamanlı PHP işlem sayısını belirler; paketin limiti bunun altındaysa 503 hatası kaçınılmazdır.
4. Önbellek payını artırın: Ürün ve kategori sayfalarını tam sayfa önbelleğe alın; yalnızca sepet ve ödeme dinamik kalsın. Böylece aynı kaynak birkaç kat fazla ziyaretçiyi karşılar. Yöntemler web sitesi hızlandırma rehberi yazısında.
5. Yük testi yapın: Kampanyadan bir hafta önce test aracıyla hedef eş zamanlı kullanıcıyı simüle edin; kırılma noktasını görmeden kampanya açmayın.

Paylaşımlı kurumsal pakette limit aşılıyorsa VPS/VDS’e geçişi kampanyadan önce planlayın.

Güvenlik ve uyumluluk: SSL, PCI DSS, KVKK

• SSL: Tüm site HTTPS; ödeme hacmi yüksekse OV ya da EV sertifika, sertifika ayrıntısında şirket adının görünmesi güven sağlar. Türler SSL sertifikası nedir yazısında.
• PCI DSS: Kart bilgisini kendi sunucunuzda saklamıyorsanız (sanal POS ya da ödeme sağlayıcısının barındırdığı form) yükümlülükleriniz en düşük seviyededir; yine de sitenin güvenlik duvarı, güncel yazılım ve erişim kontrolü gerektirir. Kart verisini kendiniz işlemeyi planlıyorsanız paylaşımlı hosting uygun değildir, ayrılmış sunucu ve denetim gerekir.
• KVKK: Müşteri verisinin nerede tutulduğu, kimlerin eriştiği ve ne kadar süre saklandığı belgelenmelidir; sunucunun Türkiye’de olması ve erişim kayıtlarının tutulması süreci kolaylaştırır.
• Web uygulama güvenlik duvarı (WAF) ve hız sınırı: SQL enjeksiyonu ve XSS’i uygulamaya ulaşmadan keser; ödeme formundaki rate limit ve CAPTCHA çalıntı kart deneme dalgalarını durdurur.
• Erişim güvenliği: Panel ve yönetici girişinde iki adımlı doğrulama, IP kısıtlaması ve ayrı FTP hesapları; genel liste web sitesi güvenliği kontrol listesi yazısında.

Yedekleme, izleme ve SLA

Mağazada yedek, dosyalardan çok sipariş ve müşteri tablosu içindir. Üç kural:

1. Sıklık: Dosyalar için günlük, veritabanı için saatlik yedek; yoğun mağazalarda veritabanı ikili günlüğü (binlog) ile dakika hassasiyetinde geri dönüş.
2. Konum: Sunucu yedeği + sunucu dışı kopya (bulut ya da ofis). 3-2-1 kuralı burada da geçerlidir; ayrıntı yedekleme stratejisi yazısında.
3. Prova: Üç ayda bir yedeği test ortamına geri yükleyip sipariş verisinin tam olduğunu doğrulayın; test edilmemiş yedek, yedek değildir.

İzleme tarafında uptime kontrolü tek başına yetmez: ana sayfa açılırken ödeme adımı hata verebilir. Sepete ekleme ve ödeme sayfasına ulaşma akışını dakikada bir deneyen bir işlem izleme kuralı, gerçek kesintiyi yakalar. Sunucu tarafında CPU, RAM, disk ve veritabanı bağlantı sayısı eşiklerine uyarı tanımlayın; araçlar sunucu izleme ve uptime takibi yazısında. SLA sözleşmesinde ise uptime taahhüdü ve telafi, öncelik seviyesine göre destek yanıt süresi ve planlı bakım bildirimi maddelerini arayın.

E-ticaret hosting karar tablosu ve kontrol listesi

Satın almadan önce kontrol listesi:

• Eş zamanlı işlem limiti ve CPU payı yazılı olarak belirtilmiş mi?
• Redis/Memcached ve LiteSpeed (ya da eşdeğeri) var mı?
• Veritabanı yedeği hangi sıklıkta, geri yükleme kaç dakika?
• SLA ve öncelikli destek sözleşmede mi?
• Kampanya öncesi geçici kaynak artırımı mümkün mü?
• Sunucu konumu ve KVKK için erişim kayıtları?

Bu sorulara net yanıt alamadığınız paketi kısa listeden çıkarın; e-ticaret hosting kararında belirsizlik, kampanya günü kesinti olarak geri döner.