AdTech · Greenfield
A highly available traffic attribution service for a global AdTech platform.
A distributed, manual process spread across several departments was replaced by a highly available Go service. Centralized, scalable, failure-resistant. Every request on the AdTech platform gets the attribution values media buyers need for precise campaign tracking in under 10ms.
The starting point
Traffic attribution spread across several departments. Cumbersome. Not scalable.
Traffic attribution at a global AdTech platform was spread across several departments. No central system, no consistent process, no scalable solution. As traffic grew and campaign numbers rose, the problem grew with them.
Media buyers could only track a fraction of the possible campaigns because attribution could not keep up with the growth of the platform. Every request on the platform needed additional attribution values to assign traffic properly, but a central service that could deliver them reliably and fast did not exist.
The challenge
Highly available. Under 10ms. No single point of failure.
The requirements were clear and uncompromising: the service has to enrich every request on the AdTech platform with attribution values in under 10ms. It must not fail, because every outage directly affects campaign tracking across the whole platform.
At the same time the service had to be available globally. Most traffic came from the EU and the US, and both regions needed their own independent, highly available instance. And the attribution values had to stay consistent across several cache layers, assigned per day and managed atomically.
My approach
Centralized.
Optimized.
Failure-resistant.
Go service with multi-region deployment
Go as the language of choice because of its native support for high concurrency and low latency. The service is deployed in the EU and the US, each region independent and highly available. AWS Global Accelerator routes traffic to the nearest region, an ALB spreads the load within the region. No single point of failure, no cross-region bottleneck.
Layered cache architecture
Three cache layers for maximum performance: an in-memory cache for frequently requested values, Valkey for distributed caching within a region, DynamoDB for persistent daily assignment of attribution values with atomic transactions. The right cache at the right time.
Attribution values managed per day and atomically
Attribution values are assigned per day and managed atomically through DynamoDB transactions. No race conditions, no double assignment, no inconsistent states, even under heavy load.
Multi-tenant architecture
The service is built multi-tenant from the ground up. Multiple tenants run isolated and securely on the same infrastructure, each with its own attribution values, without affecting one another.
Integration into the AdTech platform
Every request on the platform is enriched through the new service. Clean integration without changes to existing systems. The platform gets the attribution values in under 10ms, media buyers can track and optimize more precisely.
What was hard
Two regions, one truth.
Independent regions and one shared sequence are a contradiction. EU and US were meant to work without each other, each highly available on its own, with no cross region bottleneck. At the same time the attribution values were issued per day and must not collide. Take both literally and you are stuck: real independence means one region cannot know what the other just issued.
The only way out was to stop implementing the contradiction and split the value range instead. Each region issues from its own range, made atomic through DynamoDB. Every value is unique without the regions coordinating in the request path. The price: values are no longer strictly consecutive. That was the point where a business promise had to change so the technical one could be kept at all.
Before any of that, someone had to decide which number was right. Attribution was spread across several departments, each with its own reporting and its own figures. As long as it was not settled which of them would be authoritative, any central service would only have cemented the disagreement. That question was not technical. It was a decision that had to be made and backed before the first service went live.
The outcome
5x more campaigns. Under 10ms. Available worldwide.
more campaigns trackable
Media buyers can track five times as many campaigns as before.
latency per request
Reliably under 10ms even under load, thanks to the layered cache architecture.
requests a day
Processed reliably, highly available in the EU and the US, no production outage since launch.
A distributed, manual process spread across several departments was replaced by a central, highly available Go service. Media buyers can track five times as many campaigns as before. Every request on the platform gets the attribution values needed for precise campaign tracking in under 10ms. The service runs highly available in the EU and the US, scales automatically with traffic and has not caused a single production outage since launch.
Technologies used
Proven tools. No experiment.
- Golang
- gRPC
- REST
- In-Memory Cache
- Valkey
- DynamoDB
- AWS ECS
- EC2
- ALB
- Global Accelerator
- IAM
- Terraform
- Docker
- OpenTelemetry
- Datadog
- Grafana
- CloudWatch
Client voices
What clients say.
“Mr Rutte built a fully custom CRM for us, tailored exactly to our needs. Working together was straightforward. He implemented our requirements perfectly and the system runs absolutely stable.”
“Tim worked with us as a PHP developer and did a really good job. He got up to speed on the project quickly and always found a solution, even on tricky topics. The code was clean, easy to follow and genuinely moved us forward. We would work with Tim again any time.”
“The development of our software was completed as agreed and all problems were resolved. Many thanks.”
Frequently asked
What clients ask before deciding.
How long did the greenfield build take?
The first productive part went live after about three months, the full replacement of the manual process after around nine. Delivery was continuous in increments, not a single cutover date.
Why Go and not the existing language?
Because the service had to answer 3 million requests a day in under 10 milliseconds while separating several tenants. Go gives predictable runtime behaviour at low memory cost. The existing PHP landscape stayed and was connected over gRPC.
What was the hardest part?
Not the technology but deciding which data was true. The manual process ran across several departments, each with its own spreadsheet. Before the first line of code came the question of which source governs in which case.