Tim van Leuverden,

Een clean-sheet, multi-tenant ELTC (Extract, Load, Transform, Charge) platform voor geautomatiseerde data-inname, transformatie en facturering. Samen met één andere backend engineer hebben we een Kubernetes-native microservice-architectuur ontworpen en gebouwd met ~25 services in Rust en Go, allemaal communicerend over gRPC met gedeelde Protocol Buffer contracten en gegenereerde Go en TypeScript SDKs.

We bouwden een data-extractieservice (Rust) die data kon ophalen van HTTP APIs (met OAuth2, JWT en cloud IAM authenticatie), relationele databases (MySQL, PostgreSQL, SQL Server, Oracle) en cloud storage (S3, Azure Blob, GCS). Een data-laadservice (Go) nam vervolgens de geparseerde data (JSON, XML, CSV, Parquet) op in PostgreSQL met automatisch schemabeheer, en een datatransformatieservice (Go) paste SQL-gebaseerde normalisatie toe op de geladen data. Tot slot schreven we een factureringsengine (Rust) die configureerbare factureringsregels uitvoerde met ondersteuning voor staffelprijzen, volumekortingen, toeslagen en incrementele facturering (zoals belastingschijven).

We maakten de pijplijn-orchestratie volledig Kubernetes-native: een workflow-orchestratie-engine (Rust) loste jobafhankelijkheden op en plande ELTC-stappen als K8s Jobs via een job-orchestratieservice (Go), terwijl een dedicated watchdog-service (Go) real-time de jobstatus terugrapporteerde. Elke tenant kreeg zijn eigen Kubernetes namespace met geïsoleerde PostgreSQL en MongoDB instanties, ingericht door een dedicated tenant lifecycle manager. Rapportage draaide op Cube.js met Keycloak authenticatie en Cerbos autorisatie. We rolden de volledige stack uit via Helm charts met OpenTelemetry instrumentatie voor observability.

Mijn primaire bijdragen waren de data-extractieservice, factureringsengine, een custom template engine (Rust, ook gecompileerd naar WASM), een pluggable storage-abstractielaag en een CLI-tool. Daarnaast heb ik significant bijgedragen aan de workflow-orchestratie-engine, datatransformatieservice, tenant agent, data-laadservice en databasemigraties.

Vaak als ik spelletjes ging spelen werd de vraag “wat zullen we spelen” gesteld. Ik had een site gevonden (WhatShouldIPlayOnSteam.com), die je gebaseerd op je gebruikersnaam een willekeurig spel uit je Steam bibliotheek geeft, maar dat was voor één gebruiker. Dus gingen we elkaar vragen stellen eerst “heb jij X” en daarna “zin om X te spelen?” een half uur lang, om een spel dat we gaan spelen te vinden. Dus besloot ik een site te maken die dat voor je doet, een spel vinden die we kunnen spelen.

De site bestaat uit twee delen, een VueJS frontend, en een NodeJS backend die met de Steam APIs communiceert. Tijdens het begin van development kwam ik er achter dat de Steam APIs nogal traag waren, met reactietijden van meer dan een seconde. Dus moest ik een vorm van caching toevoegen, daar voor heb ik Redis gebruikt. Na de eerste laag caching, heb ik nog een laag caching toegevoegd voor het vinden van spellen die alle spelers hebben.

Dus nu cached het de speler ID gebaseerd op “vanity URL”, een lijst van spellen per speler, en lijst van spellen die één groep spelers heeft. Gelukkig heeft Redis een makkelijke oplossing om cache items na een vaste tijd weg te gooien, dus hoef ik me geen zorgen te maken om crashes doordat de cache vol raakt.