Flash Sale Mimarisi: Kampanya Gününü Ayakta Geçirmek
Kampanya günü mimarisi: bekleme odası (waiting room), stok rezervasyon tasarımı, sıcak ürün problemi, ani trafik emilimi ve kampanya operasyon defteri — serinin tüm desenleri tek senaryoda.
Flash sale neden sıradan zirvenin katı değil, başka bir problemdir?
Çünkü trafik yalnızca büyümez, şekil değiştirir: on binlerce kullanıcı aynı saniyede, aynı birkaç ürüne, aynı 'satın al' butonuyla gelir. Normal gün mimarisinin varsayımları — dağılmış erişim, önbelleklenebilir çeşitlilik, bağımsız işlemler — tam tersine döner: tek sıcak kayıt, sıfır önbellek toleransı, kilit yarışı. Bu kapanış yazısı, serinin tüm desenlerini tek senaryoda birleştirir: kampanya gününü ayakta geçirmek.
Katman 1: Trafiği kapıda şekillendirmek — bekleme odası
Flash sale'in ilk gerçeği kabullenmedir: sistemin işlem kapasitesi saniyede X ise, saniyede 50X gelen istek ya kapıda düzenlenir ya içeride herkes için çöker. Bekleme odası (waiting room) bu düzenlemenin endüstri standardıdır: kampanya sayfasına gelenler hafif, statik bir kuyruğa alınır (CDN/edge katmanında — uygulamaya hiç inmeden); adil sıra (rastgele atanmış sıra + FIFO) korunur; kullanıcılar kontrollü hızda (saniyede N kişi) gerçek siteye bırakılır ve her giriş kısa ömürlü imzalı bir jetonla doğrulanır — kuyruk atlama URL paylaşımıyla mümkün olmamalıdır. Deneyim tasarımı önemlidir: sıradaki yerin ve tahmini sürenin gösterilmesi, belirsizlikten doğan yenileme fırtınasını (F5) engeller — ki o fırtına, bekleme odasının çözmeye geldiği yükün ta kendisidir.
Katman 2: Sıcak ürün problemi — stok ve kilit tasarımı
İçeri giren trafiğin tamamı birkaç satıra vurur: kampanya ürününün stok kaydı. Klasik 'oku-kontrol et-yaz' deseni burada iki şekilde ölür: pessimistic kilitte kuyruk, optimistic'te çakışma fırtınası. İşleyen tasarım katmanlıdır: stok, atomik sayaç olarak Redis'e alınır (DECR ile tek adımda düş-ve-kontrol; negatife düşen istek anında 'tükendi' alır — veritabanına hiç inmeden); başarılı düşüm bir rezervasyona dönüşür (TTL'li: ödeme tamamlanmazsa stok otomatik geri döner); kalıcı kayıt asenkron kuyruğa yazılır (sipariş hattı, kuyruk yazımızdaki idempotent tüketici + outbox disipliniyle). Aşırı satış (overselling) toleransı iş kararıdır: kesin sıfır tolerans atomik sayaçla; küçük tolerans + telafi (nadir iptal/özür) ise daha yüksek throughput'la gelir — seçim bilinçli yapılır ve yazılır. Sayaç parçalama (sharded counter), tek anahtarın bile darboğaz olduğu en uç ölçeğin aracıdır.
Katman 3: Sayfayı ucuzlatmak — her istek emilmeli
Kampanya sayfası, normal ürün sayfasının aksine tamamen statikleştirilir: içerik CDN'de, fiyat ve görseller sürümlü URL'lerle, sayaç/stok durumu ise tek küçük uç noktadan kısa TTL'li olarak beslenir. Kişiselleştirme, öneriler, gerçek zamanlı olmayan her şey kampanya şablonundan çıkarılır — önbellek yazımızdaki emilim ilkesinin en sert uygulamasıdır: uygulamaya inen her istek, inmek zorunda olduğu için inmelidir. Aynı disiplin API tarafında da geçerlidir: mobil uygulama kampanya ekranı, tek toplu uçtan beslenir; 'her widget bir çağrı' deseni kampanya günü intihardır.
Katman 4: Serinin desenleri sahnede
Desen (yazı) | Kampanya günündeki rolü |
|---|---|
Kapasite matematiği (1) | Ön-ölçekleme: beklenen zirve × pay; autoscaling'e güvenilmez, önceden büyütülür |
Önbellek + stampede (2) | Sayfa emilimi; kampanya başlangıcında topluca dolan anahtarlar için ön-ısıtma |
Veri katmanı (3) | Okumalar kopyalarda; sıcak sayaçlar Redis'te; sipariş yazması partisyonlu |
Kuyruk + backpressure (4) | Sipariş hattı asenkron; kuyruk derinliği kampanyanın nabız göstergesi |
Rate limit + shedding (5) | Bot/kötüye kullanım kapıda; süsler önce atılır, ödeme korunur |
Dayanıklılık (6) | Ödeme sağlayıcısına breaker; bağımlılıklar bulkhead'li |
Saga + tutarlılık (9) | Rezervasyon→ödeme→sipariş akışı telafili; durum şeffaf |
Operasyon: kampanya bir mühendislik etkinliğidir
Mimari kadar operasyon da tasarlanır. Önce: üretim benzeri yük testi (kampanya senaryosuyla — normal trafik profiliyle değil), ön-ölçekleme ve önbellek ön-ısıtma planı, özellik bayraklarıyla 'kampanya modu' (ağır özellikler kapalı), yazılı runbook ve rol dağılımı. Sırasında: tek ekran kampanya panosu (kuyruk derinliği, stok sayacı, hata oranı, p99, DLQ), donma penceresi (kampanya saatinde dağıtım yok) ve karar yetkisi belli bir savaş odası. Sonra: uzlaştırma (rezervasyon-ödeme-stok tutarlılığı), TTL'i dolan rezervasyonların iadesi ve ölçümlerle retrospektif — bir sonraki kampanyanın kapasite matematiği bu veriden çıkar.
İş etkisi: kampanya günü, mimarinin bilançosudur
Flash sale, yazılım mimarisinin ciroya en doğrudan çevrildiği andır: ayakta kalan sistem kampanya bütçesinin karşılığını satışa çevirir; çöken sistem aynı bütçeyi rakibe reklam yapar — sosyal medyada 'site çöktü' etiketiyle. Bu seride kurulan disiplinlerin toplamı tam da bu güne hazırlıktır: emilim oranı, kapasite matematiği, backpressure, kontrollü küçülme ve akış bütünlüğü. Kampanya sabahı sorulacak tek soru kalmalıdır: 'runbook'taki hangi adımdayız?' — 'şimdi ne yapacağız?' değil.
Sık sorulan sorular
Bekleme odası hazır servis mi, kendi geliştirmemiz mi olmalı?
CDN sağlayıcılarının hazır bekleme odası ürünleri çoğu senaryo için hızlı ve güvenli başlangıçtır; çok özel adalet/öncelik kuralları (sadakat segmenti önceliği gibi) gerekiyorsa edge üzerinde özel geliştirme değerlendirilir.
Stok sayacında Redis düşerse ne olur?
Senaryo yazılı olmalıdır: kalıcılık modu (AOF) + yedek düğüm temel önlemdir; yine de kayıp ihtimaline karşı 'satışı durdur + veritabanından yeniden kur' prosedürü ve rezervasyon kayıtlarından geri sayım hazır tutulur.
Kampanyada autoscaling neden yetmez?
Ani dikey sıçramada yeni kapasitenin açılma süresi (dakikalar) ilk dalgayı karşılayamaz. Bilinen zirve önceden ölçeklenir; autoscaling gün içi dalgalanmayı yönetir, açılışı değil.
Bot ve stokçularla mücadele nasıl kurgulanır?
Katmanlı: bekleme odası jetonu + cihaz/davranış analizi + hesap-adres bazlı adet sınırı + şüpheli desende doğrulama. Tek araç yetmez; amaç botu sıfırlamak değil, gerçek müşterinin şansını korumaktır.
Kampanya günü kontrol listesi
Kampanya senaryolu yük testi yapıldı; ön-ölçekleme planı onaylı
Bekleme odası kurulu; jeton doğrulaması ve adil sıra test edildi
Stok atomik sayaçta; rezervasyon TTL'i ve iade akışı çalışıyor
Kampanya sayfası statikleştirildi; önbellek ön-ısıtması planlı
Kampanya modu bayrakları hazır; donma penceresi ilan edildi
Tek ekran pano + runbook + savaş odası rolleri tanımlı
Kampanya sonrası uzlaştırma ve retrospektif takvimli
SSH Yazılım, kampanya günü mimarisini — bekleme odasından stok tasarımına ve operasyon defterine — uçtan uca kurar. Bir sonraki büyük gününüzü birlikte kazanca çevirelim.