KillReport

The Problem

Every fight in the game produces a killmail record, and these records never stop flowing. Enriching each record takes many requests to an external API, and that API has a strict rate limit.

Leaderboards and the live feed must stay current without delay; a worker crashing or restarting must not take the site down.

Architecture

The API server and the workers are separate processes that talk to each other only through Redis, so each can be restarted independently.

What I Built

• Live Feed

  New killmails appear on the page instantly through GraphQL subscriptions.

• Characters, Corporations, Alliances

  History, statistics and automatic syncing for every entity.

• Leaderboards

  Daily counters are updated in the same transaction as the record; no separate scheduled job is needed.

• Sovereignty and Map

  Tracking of regions, star systems and sovereignty campaigns.

• Worker Dashboard

  A monitoring screen that shows the state of queues and workers.

• EVE SSO

  Players sign in with their own EVE account; tokens are refreshed automatically.

Hard Problems I Solved

1. 1

   A Rate Limit Shared Across Processes

   ESI allows 150 requests per second. Because dozens of workers share the same limit, I wrote a common Redis-based limiter and kept it at 50 requests per second as a safety margin.

2. 2

   Current Leaderboards Without Scheduled Jobs

   Daily counters are incremented atomically in the same database transaction that stores the killmail. Leaderboards are never stale and no separate cron job is needed.

3. 3

   Protecting Tables Outside the Schema

   I added a safeguard that stops hand-written tables, created for performance, from being dropped by ORM migrations.

Technologies

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

Related Services

• APIs and GraphQL (in Turkish)
• PostgreSQL and Databases