KillReport

Problem

Oyunda her çatışma bir killmail kaydı üretir ve bu kayıtlar durmadan akar. Her kaydı zenginleştirmek için dış API’ye birçok istek atmak gerekir, ama API’nin sıkı bir hız sınırı vardır.

Liderlik tabloları ve canlı akış gecikmeden güncel kalmalı; bir işçinin çökmesi ya da yeniden başlaması siteyi durdurmamalı.

Mimari

API sunucusu ve işçiler ayrı süreçler; birbirleriyle yalnızca Redis üzerinden konuşur, bu yüzden bağımsız yeniden başlatılabilirler.

Neler Yaptık

• Canlı Akış

  Yeni killmail’ler GraphQL abonelikleriyle sayfaya anında düşer.

• Karakter, Korporasyon, İttifak

  Her varlık için geçmiş, istatistik ve otomatik senkronizasyon.

• Liderlik Tabloları

  Günlük sayaçlar kayıtla aynı işlemde güncellenir; ayrı bir zamanlanmış iş gerekmez.

• Egemenlik ve Harita

  Bölge, yıldız sistemi ve egemenlik kampanyalarının takibi.

• İşçi Paneli

  Kuyruk ve işçilerin durumunu gösteren izleme ekranı.

• EVE SSO

  Oyuncular EVE’nin kendi hesabıyla giriş yapar; tokenlar otomatik yenilenir.

Çözdüğümüz Zor Problemler

1. 1

   Süreçler Arası Paylaşılan Hız Sınırı

   ESI saniyede 150 isteğe izin veriyor. Onlarca işçi aynı sınırı paylaştığı için Redis tabanlı ortak bir sınırlayıcı yazdık ve güvenlik payıyla saniyede 50 istekte tuttuk.

2. 2

   Zamanlanmış İş Olmadan Güncel Tablolar

   Günlük sayaçlar, killmail’in kaydedildiği veritabanı işleminde atomik olarak artırılıyor. Liderlik tabloları hiçbir zaman eski kalmıyor ve ayrı bir cron işine gerek yok.

3. 3

   Şema Dışı Tabloların Korunması

   Performans için elle yazılmış tabloların ORM göçlerinde silinmesini engelleyen bir koruma ekledik.

Teknolojiler

• Next.js
• React
• TypeScript
• GraphQL
• Prisma
• PostgreSQL
• Redis
• RabbitMQ
• GitHub Actions

İlgili Hizmetler

• API ve GraphQL
• PostgreSQL ve Veritabanı