Case study

Arena Affiliates

An iGaming affiliate platform rebuilt end to end: partner networks, CPA/RevShare commissions, CSV ingestion, conversion analytics, and period closing — Laravel + React on Google Cloud, with the legacy Nest/GKE stack retired after a dual-run cutover.

Introduction

Arena Affiliates is the affiliate operating system for Grupo Dupla: it tracks traffic from campaign links through registration, first-time deposit, and CPA, then settles commissions across a master → sub-affiliate tree. I led the rebuild of the product from a legacy Nest.js service on GKE to Laravel 12 and React, and I own the infrastructure it runs on — Compute Engine, Cloud SQL, Docker, Redis workers, and GitHub Actions for homolog and production.

Affiliate hierarchies with versioned CPA / RevShare / FTD agreements
Partner, campaign-link, and request workflows for the commercial team
Async CSV ingestion (queued process + apply) for partner performance files
Analytics: conversion funnels (Reg → FTD, FTD → CPA), click volume, week/month trends
Financial close: balances, withdrawals, NF-e and receipt uploads, period simulation/execute
Partner-facing postback API with scoped tokens; Sanctum auth and optional TOTP 2FA

Role — Lead developer: architecture, backend, frontend, and all infrastructure. I work day to day with data and business, mentor one engineer, and am the person accountable when homolog or production misbehaves.

Technologies — Laravel, PHP, React, PostgreSQL, Redis, Docker, Google Cloud, GitHub Actions — PHP 8.4 in Docker on Compute Engine; PostgreSQL on Cloud SQL; Redis for queues and cache; Nginx in front of the app.

Purpose and Goal

The legacy stack could not keep up with how the affiliate team actually works: large partner CSVs, network commissions that have to be explainable, and deploys that were hard to reason about.

The goal was a platform the business can operate — correct numbers across the tree, a financial close they trust, and a deploy path we control — without a big-bang rewrite that would freeze commercial operations.

Planning started from production reality, not the slide: map what was already serving traffic, keep Nest and Laravel on the same Cloud SQL instance during dual-run, then cut over once homolog proved the new commission and import paths.

Spotlight

The spine of Arena is the path from a partner file to money: ingest CSV, attach rows to affiliations via partner codes, compute commissions for every level of the tree (gross, passed to subs, net for the master), and close the period. That is also where a rewrite dies if you get it wrong. The tension was dual-run — new Laravel and old Nest writing the same `arena` database — plus an infra story in the repo that did not match the VM actually serving `prodapi`. I inventoried what was running (Dockerized Laravel, workers, Redis, Nginx on Compute Engine; Cloud SQL for Postgres), stood up GitHub Actions so the `homolog` branch ships homolog and `main` ships production, and made commission math explicit in versioned agreements instead of implied by spreadsheet columns. Queues split processing from applying so a 200k-row file is a job, not a timeout.

Lessons Learned

Owning infra means verifying what is live — DNS, VMs, compose files — before trusting the migration doc.
Dual-run on a shared database is a deliberate cutover tool; correlation and idempotent imports matter more than a greenfield schema.
Commission models belong in versioned agreements. Gross vs passed vs net has to be the same sentence for finance and for the API.
CSV at affiliate volume needs a two-step queue (process, then apply) or the HTTP request becomes the product.