Canlı bir online oyunda backend çalışması

Haziran 2026'da, gerçek oyuncularla hâlihazırda çalışan bir online oyun olan Age of Pirates Online üzerinde backend mühendisi olarak çalıştım. İş üç alanı kapsıyordu: bir ödeme API'si eklemek, backend'i ve web sitesini hızlandırmak ve oyun sunucusu ile web sitesi arasındaki iletişimi sağlamlaştırmak.

Bu bir production sistemi olduğu için bu yazı, iç yapının nasıl kurulduğuna değil, neyin ve neden yapıldığına odaklanıyor.

Hâlihazırda canlı olan bir sistem üzerinde çalışmak

Canlı bir oyundaki temel kısıt, siz bir şeyleri değiştirirken oyuncuların çevrimiçi olmasıdır. Devam eden oturumları bozan ya da uzun bir bakım penceresi gerektiren bir değişiklik, oyuncular tarafından anında hissedilir. Bu, aşağıdaki üç işin hepsi için geçerli.

Ödemeler

İlk görev, Xsolla ödeme altyapısını web sitesine sıfırdan entegre etmekti. Ödemeler, bir oyunun backend'inde hataların hem oyuncular hem de işletmeci için en pahalıya patladığı kısımdır. Ödeme yapan bir oyuncu, bir istek tekrar denense ya da bir callback iki kez gelse bile, ödediği şeyi tam olarak bir kez almalıdır. Ödeme sağlayıcısından gelmeyen bir istek ise hiçbir zaman hiçbir şey verdirememelidir.

Performans: iki tarafta da yaklaşık %30

İkinci görev hızdı ve iki ayrı şey üzerinden ölçüldü:

• Sunucu tarafı işleme yaklaşık %30 hızlandı.
• Web sitesi yüklenme süresi yaklaşık %30 azaldı.

Bunlar farklı problemler. Sunucu tarafı süre, her isteğin yanıt verebilmeden önce ne kadar iş yaptığıyla ilgilidir. Yüklenme süresi ise oyuncunun tarayıcıda gerçekte beklediği süredir ve bu, ne kadar verinin hangi sırayla gönderildiğine de bağlıdır. Daha hızlı bir sunucu otomatik olarak daha hızlı bir sayfa anlamına gelmez; bu yüzden ikisini ayrı sayılar olarak takip etmek gerekir.

Web sitesindeki asıl sorun, her şeyi tek seferde yüklemeye çalışmasıydı. Çözümler şunlardı:

• Sayfalı JSON: bir sayfa yalnızca gösterdiği veriyi istiyor.
• Ön yükleme: oyuncunun ihtiyaç duyacağı bir sonraki şey zaten yolda oluyor.
• Yükleme başına yaklaşık 2 MB'lık bir aktarım sınırı: hedef olarak değil, kesin bir sınır olarak.
• İç içe geçmiş kodu sadeleştirmek: akışı takip etmeyi ve değiştirmeyi kolaylaştırdı.

Sunucu tarafında stack C ve PHP. Kazanç iki değişiklikten geldi:

• İşleri ana thread'den yardımcı thread'lere taşımak: yavaş bir iş artık arkasındaki her şeyi bekletmiyor.
• Düşük öncelikli iş türlerini daha seyrek çalıştırmak: bazı iş türlerine nadiren ihtiyaç duyuluyordu ama yine de sık çalışıyorlardı.

Oyun sunucusu ile web sitesi arasındaki bağlantıyı korumak

Oyun sunucusu ve web sitesi, bir dizi API gateway üzerinden veri alışverişi yapıyor. Bu gateway'ler, herhangi bir herkese açık servisin aldığı trafiğin aynısına maruz kalıyordu ve bu trafiğin bir kısmı kötü niyetliydi:

• Bir servisi hacimle boğmaya çalışan UDP flood saldırıları.
• Endpoint'lere gerçek bir oyuncunun yapabileceğinden çok daha hızlı istek yağdıran, rate limit'leri dikkate almayan botlar.
• Gateway'leri hedef alan diğer otomatik saldırılar.

Gerekli olan gateway'lerde iletişimi sağlamlaştırdım; böylece bu trafik, gerçek oyunculara hizmet veren kısımlara ulaşmadan engelleniyor. Bu; servisi sürekli kötüye kullanan IP'leri engellemek, UDP flood'ları filtrelemek ve önüne bir CDN koruma katmanı koymak anlamına geliyordu. Amaç, sistemi teoride saldırganlar için erişilemez hâle getirmek değil, bu tür trafik sürerken meşru trafiğin çalışmaya devam etmesini sağlamaktı.

Bunun çevresinde sunucunun kendisi için bir temel yapılandırma kurdum: daha sıkı erişim kontrolü, otomatik yedekler, çökme uyarılı kaynak izleme, zamanlanmış yeniden başlatmalar ve dosya izinlerinin gözden geçirilmesi.

Neler olduğunu görmek

Trafiği engellemek işin yarısı; oyun sahibinin neler olup bittiğini de bilmesi gerekiyor. Tek seferlik bir stres testi yerine, oyun sahibinin Discord'una saatlik bir rapor kurdum. Rapor trafiği, isteklerin IP'lere nasıl dağıldığını, erişim denemelerini ve her endpoint'e yönelik saldırıları kapsıyor. Böylece "dün gece sunucu yavaş gibiydi" hissi, bakılıp doğrulanabilen bir şeye dönüşüyor.

Çıkarımlar

• Canlı bir sistemde sunucu süresini ve sayfa yüklenme süresini ayrı ayrı ölçün; böylece iyileştirmeler izlenim değil, sayı olur.
• Ödeme işlemeyi, asla iki kez hak vermemesi ve sahte bir isteği asla kabul etmemesi gereken kısım olarak ele alın.
• Yalnızca herkese açık web sitesini değil, servisler arasındaki iç bağlantıları da koruyun.
• Trafik ve saldırıları düzenli raporlayın; böylece sorunlar oyuncular şikâyet etmeden önce sayılarda görünür.