AdZoic Labs

The engineering side of the company. We publish our architecture, the numbers we actually measure, and the bugs we find in our own code — including the ones nobody outside would ever have noticed. This page is where that work lives.

Animated: a latency line is drawn flat, spikes sharply, gets ringed and labelled 'found it', and then a teal line is drawn over the top showing the same measurement flat again.
How we work

Build, measure, publish, fix

The loop is ordinary. The only unusual part is that the third step happens whether or not the news is good.

Animated diagram: a marker travels through four stages — build, measure, publish, fix — with a return path underneath labelled 'and round again, including the part where we were wrong'.
The rules we hold ourselves to

Four of them, and they bite

Measure, then claim

No number goes on this site unless someone can pull it from a dashboard on request. When we found a capacity claim on our own blog that was roughly ten times too high, we corrected the page and said so in public.

Date the figures

Performance numbers are a snapshot, not a service level. Every production figure we publish names the window it was measured in, because the honest answer to "how fast is it?" changes with the traffic.

Publish the bugs

If we find something broken in our own code, the write-up goes out — what it was, how it hid, and what we changed about testing so the next one is caught. A defect nobody hears about teaches nobody anything.

Say what we don't share

Some things stay in. We don't publish versions, endpoints, thresholds or security configuration, and we don't publish our fraud signals or bid-pricing logic. We'd rather name the gaps than pretend there aren't any.

The record

What that has added up to

6engineering write-ups published
3public corrections to our own claims
0invented numbers
100%of figures re-checkable on request
Read the work

Written up in full

ARCHITECTURE

Inside the platform

The stack, the system diagram, the security posture and how we scale — with a section on what we deliberately leave out, and why.

POSTMORTEM

The jitter that never jittered

A retry delay meant to be random returned the same number 100,000 times. The test we had written for it passed, comfortably.

MEASUREMENT

How we load test

A load test gates every merge. Reading our own report properly showed it had been measuring our rate limiter rather than our bidder.

INFRASTRUCTURE

Measure first, buy last

The whole platform is written as code, and most of our best fixes turned out to be a measurement rather than a purchase — three copies of every message, with no machines bought.

COST

The free road to S3

For weeks, our logs and backups paid a per-gigabyte toll to reach storage that was free to reach. One small change moved them onto a road AWS doesn't charge for.

CONTEXT

Contextual targeting without cookies

Most bid requests arrive with no page to read. We rebuilt the context engine to understand sites and apps before the auction and look them up in a fraction of a millisecond — and we say what we haven't measured yet.

If you are here to understand the industry rather than our stack

Start with the plain-English path instead — it explains how ad buying works from the beginning, with no engineering assumed. New pieces from both tracks land on the blog.

We are usually hiring engineers.

If publishing your own postmortems sounds like a good way to work rather than an alarming one, we should talk. Everything above was built by a small team in Dhaka.

See open roles