A case study on creating a data product from scratch and scaling it across 10+ operator clients.

The Problem

GiG's operator clients — the casino, sportsbook, and lottery brands running on GiG's platform — wanted to send personalised messages to players based on what those players were doing right now. Not what they did yesterday. Not what showed up in a report this morning. Right now.

A player who just deposited €500 should get a different experience than someone who hasn't logged in for a week. A player on a losing streak might need a responsible gaming intervention. A high-value player browsing a new game category should see a relevant bonus offer.

The problem was that GiG's data platform wasn't connected to the CRM tools operators used — platforms like Symplify and FastTrack. Player events were being captured and stored, but they weren't flowing to the systems where operators could actually act on them.

There was no product for this. No roadmap item. No team assigned to build it.

What I Built

I initiated and built GiG Broker CRM — a real-time CRM data pipeline that captured live player events from GiG's data platform and delivered them to external CRM platforms.

The architecture:

• Source: Player events streaming through Kafka — deposits, withdrawals, bets, game launches, logins, registration events, and more
• Processing: Event enrichment and filtering to match each operator's specific CRM requirements. Different operators wanted different events, in different formats, at different frequencies
• Delivery: Real-time push to CRM platforms (Symplify, FastTrack, Intellitics), with each operator getting their own configured feed
• Monitoring: Production alerting on delivery latency, event throughput, and failure rates

The trickiest part was the multi-tenancy. GiG serves 10+ operator clients on the same platform, and each one had different requirements for which events they wanted, how they wanted them formatted, and which CRM platform they used. The pipeline had to be configurable per-operator without requiring code changes for each new client.

The Outcome

Broker CRM scaled from zero to 300,000 events per hour, serving 10+ operator clients across casino, sports betting, and lottery verticals.

For operators, this meant they could trigger personalised player actions in real-time for the first time — bonus offers based on live behaviour, responsible gaming interventions at the right moment, and re-engagement campaigns triggered by actual inactivity patterns rather than batch reports.

For GiG, it became a product differentiator. The ability to offer real-time CRM integration was a selling point that competitors didn't have, and it gave existing clients a reason to deepen their use of the platform.

What I Learned

The best products come from noticing gaps. Nobody asked me to build Broker CRM. I saw operators struggling with stale data in their marketing tools and built a solution. Sometimes the most valuable thing an engineer can do is identify a problem that nobody has formally articulated yet.

Multi-tenant data products are a different beast. Building a pipeline for one client is straightforward. Building one that serves 10+ clients with different requirements, without creating 10 separate pipelines, requires careful abstraction. Getting the configuration layer right was more important than optimising the throughput.

Owning the full lifecycle changes how you think. I handled everything from stakeholder coordination and third-party integrations to development, deployment, and production monitoring. When you're on call for the system you built, you design it differently. You think about failure modes. You build better alerts. You write documentation that your future self will actually use at 2am.

I'm Julian Calleja, a Senior Data Engineer focused on real-time data platforms in iGaming. Currently building at Elantil, previously at GiG and SpinCity. Get in touch if you want to talk about data infrastructure or iGaming.