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

3engineering write-ups published
2public 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.

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