281.000 Sayfa Nasıl Hızlı Kalır?

281.000 parfüm sayfası. Her birinde notalar, akorlar, görseller, puanlar, benzer parfümler. Bu veriyi her sayfa yüklemesinde veritabanından çekip, işleyip, kullanıcıya sunmak — gecikme kaçınılmaz olurdu.

Ama gecikme kabul edilemez. Bir kullanıcı parfüm aradığında, sayfa açıldığında, listeyi kaydırdığında — her anın anında hissettirmesi gerekiyor. Hız bir teknik metrik değil, kullanıcıya duyulan saygı.

Statik Ama Taze

Geleneksel yaklaşımda iki seçenek var: her sayfayı önceden oluşturup statik dosya olarak sunmak (hızlı ama eski veri riski) ya da her isteği anında işlemek (taze ama yavaş).

Biz üçüncü bir yol kullanıyoruz: artımlı statik yenileme. Sayfalar önceden oluşturuluyor — bir kullanıcı bir parfüm sayfasını ziyaret ettiğinde, sunucudan gelen hazır bir dosyayı alıyor, canlı veritabanı sorgusu yok. Ama bu dosyalar belirli aralıklarla yenileniyor: arka planda yeni versiyon oluşturuluyor, bir sonraki ziyaretçi güncel versiyonu görüyor.

Sonuç: veritabanı sorgusu hızında statik dosya, statik dosya güvenilirliğinde taze veri.

Önceden Hesaplanmış Cevaplar

"Bu markanın kaç parfümü var?" sorusunu düşünün. Naif yaklaşım: her sayfa yüklemesinde tüm parfümleri sayın. 15.000 marka için bu, binlerce gereksiz sayma işlemi demek.

Daha iyi yaklaşım: bu cevabı önceden hesaplayın ve saklayın. Veritabanında "materyalize görünümler" kullanıyoruz — sık sorulan soruların cevaplarını periyodik olarak hesaplayıp saklayan yapılar. Marka başına parfüm sayısı, nota başına kullanım sıklığı, akor istatistikleri — hepsi önceden hazır.

Sorguyu değil, cevabı önbelleğe almak. Bu basit fikir, sayfa yükleme sürelerini dramatik şekilde kısaltıyor.

Katmanlı Önbellekleme

Tek bir önbellek yeterli değil. Farklı veri türleri farklı tazelik gereksinimleri taşır, ve aynı veri farklı seviyelerde tekrar tekrar isteniyor.

İlk katman: aynı sayfa yüklemesi içinde tekrarlanan istekleri birleştirme. Bir sayfa hem üst menüde hem içerikte aynı marka bilgisini gösteriyorsa, veritabanına tek bir istek gider.

İkinci katman: farklı kullanıcılar arasında paylaşılan önbellek. "Dior" marka sayfasını her gün binlerce kişi ziyaret ediyor — her biri için ayrı sorgu yapmak yerine, sonucu saklayıp paylaşıyoruz.

Üçüncü katman: veritabanının kendi içindeki ön hesaplama. Materyalize görünümler burada devreye giriyor — veritabanı düzeyinde önbellek.

Her katman farklı bir problemi çözüyor: birincisi gereksiz tekrarı, ikincisi gereksiz hesaplamayı, üçüncüsü gereksiz toplamayı.

Sadece Gerekeni Getir

Bir parfümün veritabanında onlarca alanı var: nota listesi, akor dağılımı, parfümör bilgisi, açıklama, çeşitli meta veriler. Ama bir listeleme sayfasındaki kart sadece beş şey gösteriyor: isim, marka, yıl, puan, görsel.

Her sorguda tüm alanları getirmek, bantgenişliği israfı ve gereksiz işlem gücü demek. Bunun yerine her kullanım senaryosu için gereken alanları önceden tanımlıyoruz. Kart görünümü için minimal set, detay sayfası için tam set, koleksiyon görünümü için ara set.

Bu yaklaşım özellikle mobil kullanıcılar için kritik. Daha az veri transferi, daha hızlı yükleme, daha az pil tüketimi.

Hız Bir Özellik Değil

Hızı bir özellik olarak düşünmek yanıltıcı. Hız bir özellik değil, bir temel. Üzerine her şeyin inşa edildiği zemin. Yavaş bir uygulama üzerine ne kadar özellik eklerseniz ekleyin, deneyim kötü kalır.

Bir kullanıcı sayfanın yüklenmesini beklerken, o saniyeler sadece teknik bir metrik değil — kaybedilen ilgi, azalan güven, terk edilen keşif.

281.000 sayfa hızlı kalabiliyorsa, 28 sayfa da hızlı kalabilir. Mesele ölçek değil, öncelik.