100 Bin İsteği Saniyede İşlemek: Sipariş İptal Butonunu Ölçeklendirmek

Süper hızlı teslimat uygulamalarından birinde dondurma siparişi verirken, 10 dakika geçti ve dondurma trafikte sıkıştı. "Sipariş İptal Et" butonuna basmak istediniz — ancak butonun kaybolması gereken an tam da bu andır. Sürücü kapınıza ulaştı mı? Uygulama bunu nasıl anında algılar?

Bu basit kullanıcı senaryosu, milyonlarca kullanıcıyı aynı anda destekleyen bir sistemde devasa bir teknoloji sorununu ortaya çıkarır. Peki, saniyede 100 binden fazla talebi nasıl yönetirsiniz? Yanıt, zamanlamadan kaçınmak ve olaylara odaklanmakta yatıyor.

Gerçek Zamanlı Kullanıcı Davranışları ve Sistem Yükü

Uygulama kullanıcılarının davranışları, arka uç sisteminde beklenmedik bir trafik dalgasına neden olur. Bu yükün kaynağını anlamak, doğru çözümleri geliştirmek için kritik önem taşır:

• Harita İzleyicileri: Kullanıcılar, teslimat ekibinin hareketini izlemek için harita ekranında kalır. Uygulama, 30 saniyede bir otomatik olarak yenilenir. 15 dakikalık bir teslimatta, bu 30 kez yenileme anlamına gelir — her kullanıcı başına 30 istek.
• Destek Sohbetini İzleyenler: Bazı kullanıcılar, müşteri hizmetleri sohbetini açar. Uygulama, sayfa yüklendiğinde iptal hakkını yalnızca bir kez kontrol eder. Ancak, sürücü kapıya ulaştığında butonun anında kaybolması gerekir — sayfa yenilemesi olmadan.

Bu iki eylem türü, arka uç sisteminin saniyede 100 binden fazla isteği işlemesi gereken bir senaryoya yol açar.

Üç Temel Sistem ve Kurallar

Sistem, üç ana bileşenden oluşur:

• Kullanıcı Arayüzü (UI): Müşterinin uygulaması (Harita ve Sohbet sayfaları).
• Eligibility Servisi: "Sipariş iptal butonunu şu anda göstermeli miyim?" kararını veren beyin.
• Teslimat Servisi: Sürücü GPS'ini ve durumunu izleyen kas gücü.

Bu sistemlerin uyması gereken kurallar şunlardır:

• Zaman > 10 dakika olduğunda → Buton göster.
• Sürücü Durumu = "Kapıda" olduğunda → Butonu hemen gizle.
• Sistem, saniyede 100 binden fazla isteği sorunsuzca işleyebilmeli.

Başarısız Olan Çözümlerden Akıllıca Olana

Çözüm 1: Zincirleme API Çağrıları (Doğrudan Bağlantı)

En bariz yaklaşım, basit bir zincir oluşturmaktır. Kullanıcı arayüzü yenilendiğinde, Eligibility Servisi, en son güncellemeyi almak için doğrudan Teslimat Servisine başvurur.

Neden kötü? Teslimat Servisi, sürekli değişen GPS koordinatlarını ve sürücü atamalarını güncellemekle meşguldür. Saniyede 100 bin okuma isteğiyle bombardımana tutulduğunda, veritabanı kilitlenir ve tüm uygulama çöker.

Çözüm 2: "Geldik mi hala?" Döngüsü (Arka Plan İşçileri)

Teslimat Servisini korumak için, Eligibility Servisinde arka plan işçileri sürekli olarak sipariş durumunu sorgular ve yerel önbelleğe kaydeder.

Neden kötü? 60 bin aktif sipariş üzerinde sürekli bir döngü çalıştırmak son derece verimsizdir. Zamanın %95'inde, sürücü henüz ulaşmamıştır ve zaman dolmamıştır. Aynı soruyu tekrar tekrar sormak, sunucu kaynaklarını boşa harcar. Ayrıca, 2 saniyelik sorgulama gecikmesi, kullanıcıların butonu kötüye kullanmasına izin verebilir.

Çözüm 3: Akıllı Matematik + Olay Tabanlı Bildirimler (Büyük Teknoloji Yolu)

Büyük teknoloji şirketlerinin milyonlarca kullanıcıyı desteklemek için kullandığı yöntem budur. İki ana strateji uygulanır:

• Zamanlayıcılardan kaçının — zamanı önceden hesaplayın.
• Olaylara odaklanın — gerçek dünya değişikliklerini anında algılayın.

Adım A — Önceden Matematiği Yapın (Okuma Yolu)

Bir sipariş saat 20:00'de verildiğinde, sistem 10 dakikalık bir sayaç başlatmaz. Bunun yerine, Eligibility Servisi, son derece hızlı bir önbellek sisteminde (Redis) basit bir zaman damgası kaydeder:

İptal İzni Verilme Zamanı: 20:10:00

Harita arayüzü 30 saniyede bir yenilendiğinde, Eligibility Servisi, önbellekten milisaniyeler içinde bir arama yapar ve bu ultra-hızlı kodu çalıştırır:

const zamanAsimiGecti = mevcutZaman > iptalIzniZamani;
const kapidaSürücüVar = (surucuDurumu === "KAPIYA_ULASTI");

if (zamanAsimiGecti && !kapidaSürücüVar) {
  return gosterIptalButonu = true;
} else {
  return gosterIptalButonu = false;
}

Veritabanları kullanılmaz. Arka plan döngüleri çalışmaz. Zaman, işi bizim için yapar.

Adım B — Gerçek Zamanlı Anahtar (Yazma/Bildirim Yolu)

Peki, butonun anında kaybolması gereken destek sohbet sayfası için ne yapılmalı?

• Sürücü kapıya ulaştığında, Teslimat Servisi, bir mesaj brokerine (Kafka) anında bir bildirim yayınlar: "Sipariş 12345: Sürücü Kapıda!"
• Eligibility Servisi, bu olayı dinler ve anında Redis'teki durumu SurucuKapida = True olarak günceller.
• Sistem, bu değişikliği kullanıcının Sohbet Arayüzüne WebSocket üzerinden anında iletir.
• Buton, kullanıcının ekranından saniyenin onda biri içinde kaybolur.

Sonuç: Akıllı ve Verimli Ölçeklendirme

Büyük trafik yüklerini yönetmek, sadece daha güçlü sunucular satın almakla ilgili değildir — akıllı bir şekilde tembel olmakla ilgilidir.

• Zamanı aktif olarak izlemek yerine, önceden hesaplayın.
• Güncelleme için yalvarmak yerine, gerçek dünya olaylarını bekleyin.

Sonunda, kullanıcılar siparişlerini iptal etmek istediklerinde butonun orada olduğunu bilirler — ya da tamamen ortadan kaybolduğunu. Ve sistem, bu talebi milyonlarca kez aynı anda destekleyebilir. Tüm bunlar, milisaniyeler içinde ve neredeyse sıfır ek kaynak tüketimiyle gerçekleşir.