Çoğu işletme sahibi, günde 1000 siparişin "daha güçlü bir sunucu" meselesi olduğunu sanır. Hosting paketini yükseltir, işlemci çekirdeğini iki katına çıkarır ve sorunun çözüleceğini düşünür. Sonra ilk büyük kampanya gecesi gelir: sayfalar açılır ama siparişler bekler, ödeme bildirimi biriktikçe birikir, veritabanı tek bir tabloda kilitlenir ve donanımın yarısı boşta dururken sistem tıkanır.
Bu ölçekte gerçek şudur: sınırı belirleyen donanım değil, mimaridir. Günde 1000 sipariş, saniyede sabit bir yük değil; iki saate sıkışmış, ani sıçramalarla gelen bir dalgadır. Bu dalgayı taşıyan bir epin script altyapısı, işi parçalara böler, en kritik yolu mümkün olduğunca kısaltır ve geri kalan her şeyi sonraya erteler. Aşağıda bu mimarinin bileşenlerini tek tek açıyoruz.
1000 sipariş neden bir donanım sorunu değil, mimari sorunudur?
Günde 1000 sipariş kâğıt üzerinde saniyede 0,01 işlem demektir ve bu, en sade sunucunun bile gülüp geçeceği bir rakamdır. Ancak gerçek dağılım böyle çalışmaz. Kampanya duyurusu yapıldığı dakika, bir saatlik hacim birkaç dakikaya sıkışır ve sistem anlık olarak saniyede onlarca isteğe cevap vermek zorunda kalır. Ortalamaya göre kurulmuş her altyapı tam bu anda düşer.
Dolayısıyla tasarım ilkesi nettir: kritik yol kısa, geri kalan her şey asenkron. Müşterinin beklediği tek an, siparişin oluşturulduğu ve ödemenin başlatıldığı andır. Kod çekme, e-posta gönderimi, fatura oluşturma, tedarikçi çağrısı, bildirim ve raporlama bu anın içinde yer almamalıdır. Bu ayrımı yapan bir dijital ürün satış scripti, aynı donanımla kat kat fazla siparişi sorunsuz karşılar.
Veritabanı neden ilk çöken bileşendir ve nasıl korunur?
Bu ölçekte en sık görülen tıkanma noktası, stok tablosundaki satır kilitleridir. Yüzlerce eşzamanlı sipariş aynı ürünün kod havuzundan çekim yapmaya çalıştığında, kilit bekleyen işlemler kuyruğa girer ve zaman aşımı zinciri başlar. Çözüm, kod çekme işlemini kısa ve atomik tutmaktır: tek bir sorguda uygun kodu seç, durumunu rezerve yap ve işlemi hemen kapat. Aynı işlem içinde e-posta göndermek veya harici bir servise istek atmak, bu ölçekte affedilmeyen bir hatadır.
İkinci koruma katmanı okuma-yazma ayrımıdır. Raporlar, yönetici ekranları ve geçmiş sipariş listeleri yazma yapan ana veritabanını meşgul etmemelidir. Üçüncüsü ise büyüyen tabloların bakımıdır; sipariş, kod hareketi ve günlük kayıtları milyon satıra ulaştığında doğru indeksler ve dönemsel arşivleme olmadan her sorgu yavaşlar. Performans sorunlarının çoğu ani değil, aylara yayılan sessiz bir birikimin sonucudur.
Kuyruk ve işçi mimarisi neden pazarlık konusu değildir?
Bu seviyede kuyruk, tercih değil zorunluluktur. Ödeme bildirimi geldiğinde sistem yalnızca doğrulamayı yapar, siparişi işaretler ve işi kuyruğa bırakır. Arka planda çalışan işçiler bu işleri sırayla alır: kodu havuzdan çeker, teslimat e-postasını gönderir, faturayı oluşturur, tedarikçiye gerekiyorsa yeni sipariş açar. Böylece e-posta sunucusundaki bir yavaşlık, ödeme akışını hiçbir şekilde etkilemez.
Kuyruk mimarisinin iki kritik detayı vardır. Birincisi yeniden deneme politikası: başarısız bir iş, artan aralıklarla tekrar denenmeli ve belirli sayıda denemeden sonra ayrı bir hata kuyruğuna düşerek insana bildirilmelidir. İkincisi tekrarlanabilirlik: aynı iş iki kez çalışsa bile sonuç değişmemelidir. Bu güvence yoksa, bir yeniden deneme aynı müşteriye ikinci kodu göndermek anlamına gelir ve doğrudan zarar yazar.
| Katman | Görevi | Tipik darboğaz | Çözüm |
|---|---|---|---|
| Web sunucusu | İstek karşılama | Eşzamanlı bağlantı limiti | Yatay çoğaltma ve yük dengeleme |
| Uygulama | Sipariş oluşturma | Kritik yolda harici çağrı | Tüm yan işleri kuyruğa taşımak |
| Veritabanı | Stok ve sipariş kaydı | Satır kilidi ve uzun işlem | Kısa atomik işlem, okuma ayrımı |
| Önbellek | Ürün ve fiyat verisi | Her istekte tekrar sorgu | Kısa ömürlü önbellek ve etiketli temizleme |
| Kuyruk | Teslimat ve bildirim | Tek işçi, biriken sıra | Çoklu işçi ve öncelikli kuyruk |
| Depolama | Fatura ve kayıt | Disk dolması | Arşivleme ve dış depolama |
Önbellek nerede kurtarır, nerede seni batırır?
Önbellek bu ölçekte en büyük kazancı okuma tarafında verir. Kategori sayfaları, ürün listeleri, döviz kuru ve sabit içerikler her istekte veritabanına gitmek zorunda değildir. Doğru kurulmuş bir önbellek katmanı, veritabanı yükünün büyük bölümünü daha ilk gün ortadan kaldırır ve sayfa açılış sürelerini belirgin biçimde düşürür.
Ancak tehlikeli kısım stok tarafındadır. Stok adedi asla uzun ömürlü önbellekten okunmamalıdır. Müşteriye "stokta var" gösterip ödeme sonrası "kod kalmadı" demek, bu işte yaşanabilecek en pahalı güven kaybıdır. Doğru yaklaşım, listeleme ekranlarında kısa ömürlü ve yaklaşık bir stok göstergesi kullanmak; ödeme anında ise her zaman gerçek kaynaktan kilitli doğrulama yapmaktır. Önbellek hız içindir, doğruluk için değil.
1000 sipariş/gün altyapı bütçesinin dağılımı
- Sunucu ve veritabanı 45%
- Kuyruk, işçiler ve önbellek 25%
- İzleme ve yedekleme 20%
- CDN ve güvenlik katmanı 10%
Göremediğin arıza neden en pahalı arızadır?
Bu ölçekte sistemin çöktüğünü müşteriden öğrenmek kabul edilemez. Gerekli olan şey, dört soruyu her an yanıtlayabilen bir izleme düzenidir: bekleyen sipariş var mı, kuyruk gecikmesi ne kadar, hata oranı yükseldi mi, stok kritik eşiğin altında mı? Bu dört sinyal, sorunun kullanıcıya yansımadan önce yakalanmasını sağlar.
İzlemeyi anlamlı kılan şey ise eşikli uyarıdır. "Kuyrukta 500 iş birikti" veya "son 5 dakikada teslimat hataları yüzde 5'i geçti" gibi kurallar, doğrudan telefonuna düşmelidir. Buna ek olarak yedekleme politikası test edilmiş olmalıdır: geri yükleme denemesi yapılmamış bir yedek, yedek değildir. Kod havuzunun kaybı, bu işte tazmini olmayan tek kayıptır.
Tek tedarikçi ve tek ödeme kanalı bu ölçekte neden tehlikelidir?
Günde 1000 siparişte tek bir dış bağımlılığın iki saatlik kesintisi, günlük cironun beşte biri demektir. Bu yüzden hem tedarik hem de ödeme tarafında yedeklilik zorunludur. Ürün bazında birincil ve ikincil tedarik kaynağı tanımlanmalı; birincil kaynak yanıt vermediğinde sistem otomatik olarak ikinciye geçmeli ve bu geçiş kayıt altına alınmalıdır.
Ödeme tarafında da aynı prensip geçerlidir. İki farklı sağlayıcı aktif tutulmalı, biri hata vermeye başladığında trafiğin diğerine yönlendirilmesi tek bir ayarla mümkün olmalıdır. Olgun bir e-pin satış yazılımı bu geçişleri kod değişikliği gerektirmeden, panel üzerinden yapmanı sağlar. Kesinti anında kimse sunucuya bağlanıp dosya düzenlemek istemez; o anda ihtiyacın olan tek şey bir anahtardır.
| Kontrol | Eşik | Sıklık |
|---|---|---|
| Kuyrukta bekleyen iş sayısı | Tepe saatte 200'ü aşmamalı | Sürekli izleme |
| Sipariş oluşturma yanıt süresi | 200 ms altında kalmalı | Sürekli izleme |
| Veritabanı yavaş sorgu kaydı | Günde 10 kaydı aşmamalı | Günlük |
| Yedekten geri yükleme testi | Başarılı tamamlanmalı | Aylık |
| Yedek tedarikçi devreye alma | Otomatik geçiş çalışmalı | Aylık |
| Disk ve arşiv durumu | Kullanım yüzde 75'i geçmemeli | Haftalık |
| Yük testi | Tepe yükün iki katı taşınmalı | Çeyreklik |
Büyük duyurudan bir gün önce tepe yükün iki katıyla yük testi çalıştır. Çöken bileşeni gece yarısı değil, provada görmek istersin.
Ölçeğe hazır bir altyapıyla çalış
Pinova; kuyruk tabanlı teslimat, atomik stok kilidi, önbellek katmanı, çoklu tedarik ve çoklu ödeme yedekliliğini panelden yönetilebilir biçimde sunar. Teknik kapsam için özelliklere, lisans seçenekleri için fiyatlandırmaya bakabilirsin.
Günde 1000 sipariş için kaç sunucu gerekir?
Doğru mimaride tek güçlü uygulama sunucusu ve ayrı bir veritabanı sunucusu genellikle yeterlidir. Belirleyici olan sunucu sayısı değil, kritik yolun kısa tutulması ve kuyruk yapısıdır.
Paylaşımlı hosting bu hacmi taşır mı?
Taşımaz. Arka planda sürekli çalışan işçi süreçleri, önbellek servisi ve veritabanı ayarları paylaşımlı ortamlarda genellikle mümkün olmaz.
Stok bilgisini önbellekten göstermek doğru mu?
Liste ekranlarında kısa ömürlü ve yaklaşık gösterim kabul edilebilir. Ödeme anında stok mutlaka gerçek kaynaktan, kilitli biçimde doğrulanmalıdır.
Mevcut sistemimi bu mimariye taşımak zor mu?
Geçiş genellikle aşamalıdır: önce teslimat kuyruğa alınır, sonra stok kilidi atomik hale getirilir, ardından okuma yükü önbelleğe taşınır. Her adım tek başına ölçülebilir kazanç verir.
Bin siparişlik bir gün, iyi kurulmuş bir sistemde sıradan bir gündür; kötü kurulmuş bir sistemde ise bütün yılın en pahalı gecesidir. Aradaki farkı belirleyen şey işlemci çekirdeği değil, işi doğru sıraya koyan mimaridir. Bu mimarinin panel tarafında nasıl göründüğünü, kuyruk durumunu ve stok kilidini kendi gözünle görmek istersen canlı demo üzerinden inceleyebilir, sonrasında lisans seçeneklerini değerlendirerek altyapını ölçeğe hazır hale getirebilirsin.