Case 05 · Selected Work
The engineering floor: billions of impressions, and a marketplace that ran itself
Eleven years across two stints at the same AdTech company: four as the sole front-end engineer on a platform conversion, then a self-serve advertising marketplace built end to end, then backend services carrying tens of thousands of requests a second.
- Role
- Software Engineer, then Senior Software Engineer
- Capabilities
- Scale · Platform · Hands-on engineering
- Domain
- Advertising technology — publisher, sales and campaign operations
- Span
- Two stints, eleven years
Context
An advertising technology company running publisher, sales and campaign-operations platforms. I joined in 2011, left in 2017 to start my own company, and was asked back twice over the following two years; I returned in 2019 at a higher grade and stayed through the pandemic.
Problem and ambiguity
Three different problems over eleven years, but one recurring shape: something that worked at one scale did not work at the next, and the fix was never in the part everyone was looking at.
My role
Years one to four: the sole front-end engineer on a legacy-to-new conversion of the platform’s operator surfaces, plus QA. Year five: I asked my manager to move me to the back end and got it — I was not reassigned, I requested it. Then I built the company’s B2B self-serve advertising marketplace, reporting directly to the CTO. In the second stint I led backend and API improvements and the migration onto a new API surface.
Discovery
The operator surfaces were not a design exercise, they were a usability problem with a commercial edge: a sales pipeline that carries opportunities through confidence stages to a won deal and on into a campaign lifecycle, a campaign manager over the country, advertiser, campaign, flight, placement and creative hierarchy, and a publisher portal covering ad-slot configuration, earnings accrual and payout requests. Getting those right meant sitting with ad operations and sales rather than with a specification.
Architecture and trade-offs
The scale work was a migration of a legacy architecture onto a new API surface, and both halves came down to taking work out of the request path. Ad telemetry — every impression, click, and which element inside an ad was clicked — would have flooded the servers if each event fired its own call, so events were accumulated and shipped on a fixed interval to a separate bookkeeping service, processed outside the main system, and written back. Reporting had been generated synchronously, so a page blocked while its report ran; that moved onto worker batches, with the page loading immediately and the job reporting back when done.
Implementation and integration
The marketplace was a complete commercial surface: advertising bundled into packages and deals, a deliberately simple membership layer over a complex core, wired to the company’s API engine, with customer self-ordering and self-management, creative upload, prepaid points top-up and deduction on the buyer side, and earnings accrual and payout requests on the publisher side. Publishers could list packages, set their placements and sell.
Production controls
Report submission was made idempotent — refreshing the page could not re-trigger a job that was already running, which is the failure every user finds within a week. Multi-layer caching, database query tuning and Node.js refactoring on the hot paths.
Impact
Backend services processing tens of thousands of requests per second and billions of monthly ad impressions, with selected p95 response times brought into the sub-100 millisecond range.
Reusable learning
Both of the scale wins came from the same move — get the work out of the request path — and neither required a rewrite. The throughput number is a consequence of that decision, not an achievement in its own right, and I would rather be asked about the mechanism than the number.
Evidence pending
This decade is best carried by a slide deck rather than a repository — project P8 — because the work is too old and too client-owned to rebuild honestly.