Most ad-tech companies keep their architecture secret. We think being open builds more trust. If you give us your ad budget, you should know how the machine that spends it works. So here it is — shared the way the engineering blogs we admire do it, Netflix's above all. Plain English. No versions or configs (we explain why at the end).
The stack we run
Everything below is already named in our own job posts, so nothing here is a new secret. But seeing it in one place tells you how we build:
- The bidder is written in Go. Go is fast and predictable — and our whole budget for a decision is a few milliseconds.
- Machine learning is Python — XGBoost, LightGBM and PyTorch. We export the trained models to ONNX, an open format. That way a model trained in Python runs at full speed inside the bidder. No Python in the hot path.
- Dashboards are Laravel (PHP) APIs with a React front end. Boring, mature tools — on purpose. Campaigns, budgets and billing must never be wrong.
- Redis holds the campaign and feature cache. The bidder reads it on every request.
- Redpanda → ClickHouse is our data pipeline. Redpanda speaks the Kafka protocol; every auction event streams through it into ClickHouse, where billions of rows become reports in seconds.
- PostgreSQL is the system of record behind the dashboards. Campaigns, budgets and billing live here — the numbers that must never be wrong.
- A small Python service — our ad-channel connector — manages Demand Gen campaigns on Google's surfaces. Campaign changes go out; performance reports come back into ClickHouse, so every channel lands in the same analytics. It lives completely off the bidding path.
- Everything runs on Kubernetes on AWS (EKS), spread across several data-centre zones. All infrastructure is written as code with Terraform — no hand-built servers.
The system, on one page
Follow one request through the picture. A bid request arrives — from an exchange, or from our ad SDK on a publisher's page. The load balancer spreads the traffic. A thin ingress layer ends the TLS connection and routes the request to a bidder pod. The bidder itself checks every request — is it valid, is it allowed — before doing any work. There is no heavy API-gateway product in front of it, on purpose: every extra hop on this path costs time we don't have. The bidder never touches a database during the auction. Campaign data comes from Redis. The value of the impression comes from an ONNX model sitting right next to the bidding code. The bidder decides, answers, and moves on.
After the answer is sent, the full story of that auction flows into Redpanda, lands in ClickHouse, and shows up on a dashboard moments later. The dashboards read and write across the whole data layer — PostgreSQL for the records, ClickHouse for analytics, Redis and Redpanda for the live stuff. Training data flows back out to build the next model. The loop closes.
Nothing slow is allowed while the auction is running. Databases, model training, reports — all of that happens before or after, never during. During the auction there is only Go, one cache read, and one model inference. This one rule is most of why the numbers below are possible.
Security by design
Here is our security in plain terms. We describe layers and principles — not versions, addresses or rules. Publishing those would help attackers, so we don't.
- Encrypted everywhere. TLS on every outside connection, and between services too.
- Least privilege. Every service gets only the access it needs. No shared master keys.
- Sandboxed ads. Ads render inside sandboxed iframes, so an ad can't touch the page around it. You can see this in our public ad SDK.
- Consent comes first. The SDK reads the page's consent state (TCF, GPP, US privacy) and the server respects it. No consent means non-personalised ads.
- Infrastructure as code. Every firewall rule and permission lives in Terraform, so changes are reviewed like code and nothing drifts quietly.
- An open door for researchers. We publish a security.txt. If you find something, we want to hear about it.
How it scales
Ad traffic comes in waves, and a late answer is a lost auction. Here is how we handle that:
- Stateless bidders. Any pod can answer any request. Kubernetes adds pods when traffic rises and removes them when it falls.
- Cache first. The bidder reads from Redis and its own memory, not from a database. A traffic spike just means more cheap cache reads.
- Compute early. Anything that can be worked out before the auction — content scores, campaign eligibility, model files — is ready in advance and simply looked up.
- Everything else is async. Logging, billing and analytics happen after the answer is sent. A slow report can never slow an auction.
- Several zones at once. If one data-centre zone fails, we lose some capacity — not the service.
Speed without a big bill
Cloud bills kill ad-tech margins, so cost per request matters as much as speed. The same choices that make the system fast also make it cheap. Go uses little memory, so one server does more work. ONNX means no GPU fleet just to serve models. Caching keeps the databases small. Autoscaling means we pay for the traffic we get — not the traffic we might get someday. In sustained load tests, this architecture handles millions of ad requests per hour — thousands every second — on a footprint a seed-stage company can afford.
That figure comes from our own load tests, not audited production traffic. We say so on purpose — we would rather under-claim than over-claim. Serious partners are welcome to a private walkthrough of the details.
What we deliberately don't share
Openness has limits, and it's more honest to name them. Three things will never appear on this blog: how our fraud detection works (that would teach fraudsters how to hide), how our bid pricing works (that's the product), and software versions or configuration (that's a free map for attackers). Everything else — the shape of the system, the trade-offs, the lessons — we'll keep sharing.
Building things like this from Dhaka, for Asia? We're hiring (applications reopen soon). Curious what all this speed is for? Start with how ad auctions work or request a demo.
