Naar de inhoud
PakketArchitectuuraudit: onafhankelijke review en stapsgewijs migratieplan in 5–7 werkdagen
Projecten
Projectdetails

COMMUNITYTOOL · 2025 – HEDEN

KillReport

Een realtime platform voor het volgen en analyseren van killmails voor spelers, corporations en alliances in EVE Online. Het synchroniseert met zKillboard en de officiële API van EVE (ESI) en is volgens de licentievoorwaarden van CCP niet commercieel.

Mijn rol: Ontwerp, ontwikkeling en beheer liggen volledig bij mij.

killreport.com
achtergrondworkers
~45
datamodellen
42
gedeelde API-limiet
50 req/s
GraphQL-subscriptions
Live

Het probleem

Elk gevecht in de game levert een killmail-record op, en die records blijven onophoudelijk binnenkomen. Om elk record te verrijken zijn veel requests naar een externe API nodig, en die API heeft een strikte rate limit.

Ranglijsten en de live feed moeten zonder vertraging actueel blijven; als een worker crasht of herstart, mag de site niet stilvallen.

Architectuur

Databronnen

zKillboard · ESI

Job queue

  • RabbitMQ

Taakverdeling

Workers

  • TypeScript

~45 processen

Datalaag

  • PostgreSQL
  • Prisma
  • Redis

Persistente data en events

API

  • GraphQL Yoga

Live subscriptions

Frontend

  • Next.js

App Router

De API-server en de workers zijn aparte processen die alleen via Redis met elkaar praten; daardoor kunnen ze onafhankelijk van elkaar herstarten.

Wat ik heb gebouwd

  • Live feed

    Nieuwe killmails verschijnen via GraphQL-subscriptions direct op de pagina.

  • Characters, corporations, alliances

    Geschiedenis, statistieken en automatische synchronisatie voor elke entiteit.

  • Ranglijsten

    Dagtellers worden in dezelfde transactie als het record bijgewerkt; een aparte geplande job is niet nodig.

  • Sovereignty en kaart

    Het volgen van regio’s, sterrenstelsels en sovereignty-campagnes.

  • Workerdashboard

    Een monitoringscherm dat de status van queues en workers toont.

  • EVE SSO

    Spelers loggen in met hun eigen EVE-account; tokens worden automatisch vernieuwd.

Lastige problemen die ik heb opgelost

  1. 1

    Een gedeelde rate limit over processen heen

    ESI staat 150 requests per seconde toe. Omdat tientallen workers dezelfde limiet delen, heb ik een gedeelde limiter op basis van Redis geschreven en die met een veiligheidsmarge op 50 requests per seconde gezet.

  2. 2

    Actuele ranglijsten zonder geplande jobs

    Dagtellers worden atomair opgehoogd in dezelfde databasetransactie die de killmail opslaat. De ranglijsten zijn nooit verouderd en een aparte cronjob is niet nodig.

  3. 3

    Tabellen buiten het schema beschermen

    Ik heb een beveiliging toegevoegd die voorkomt dat tabellen die voor de performance met de hand zijn geschreven, door ORM-migraties worden verwijderd.

Technologieën

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

Gerelateerde diensten

Bouw je een vergelijkbaar systeem? Van de architectuur tot de livegang kunnen we samenwerken.

Neem contact op