Role Description
One of the engineers on the live request path of an ad-serving bridge between a supply-side platform and a Japanese broadcaster’s programmatic linear exchange. The path runs from the incoming ad opportunity through deal matching and pacing, creative and restriction filtering, selection, and the response the broadcaster receives. The client has settled on C++ for this path and treats the choice as closed.
Their reason for C++ is reuse rather than raw speed. The client is modularising its existing C++ ad server so components can be linked into this new application instead of called across a service boundary; their example was an audience and segment library, and their stated aim is that everything is bundled together and the latencies are very strict. So the engineer in this seat writes new code and consumes a library estate they did not write, inside a build system belonging to someone else. That modularisation work sits on the client’s side and carries no data, which makes it a dependency rather than a given.
The request timing comes from the broadcaster. Slots with a fixed broadcast time receive the request about a minute before air; untimed slots receive it one to three seconds before air. A single slot can produce three or more sequential sub-requests, with the request for the next segment issued while the previous commercial is still playing, so break-level state has to survive that chain. The client describes the work as high-throughput system design. The specification discloses neither a target request volume nor the response timeout, so treat the throughput requirement as stated by the client and unquantified in the documentation.
Full-time from the first milestone through production handover. Reports to our solution architect, who owns the internal model and the interface contracts, and works alongside a Go engineer on the settlement side.
About the Project
Client: an established supply-side platform operating at scale. The engagement is a fully outsourced build. The client supplies a product manager for requirements and scope, an architect in review and supervision mode, and an infrastructure specialist for the UAT and production environments. We own delivery, the architecture, and everything before UAT.
Product: an ad-serving bridge connecting the client to a Japanese broadcaster’s programmatic linear platform, built apart from the client’s core RTB stack. It works as a translation layer and as a lightweight supply-side platform running the auction. Three parties define its edges:
The broadcaster’s exchange is the source of ad opportunities, reached through a connection specification the broadcaster defines and we implement against, with no leverage to change it.
An external viewing-rating system decides how many people saw each commercial. We never call it. The exchange derives impression counts from those ratings and reports them back twice: preliminary shortly after air, confirmed the following business day.
The client’s configuration surface supplies demand as activated direct deals. An optional second phase adds third-party demand-side platforms over oRTB.
Phasing: a mandatory first phase runs entirely in the broadcaster’s native protocol and needs no protocol conversion. An optional second phase adds oRTB conversion and direct communication with demand-side platforms. The internal model is oRTB-aligned from the first phase, so the second becomes an edge-mapping job.
Position today: greenfield. Nothing is built. The broadcaster’s connection specification exists and is versioned, though its revision history shows continued amendment. The requirements document does not exist yet.
Stack: C++ on the request path, settled by the client, with Go on the settlement and reconciliation side. The system deploys into the client’s own data centres and must be built cloud-ready, in the client’s words, so that moving it to the cloud later is not a separate project.
Key Responsibilities
Request p
