Learning resource

Who this is for

Candidates. If you are interviewing with our engineering, data or platform teams, this is the problem space you will be asked about. We would rather you arrive informed than impress us cold.

Engaged users and counterparties. If your work touches these systems, this explains the shape of what is underneath without requiring you to operate it.

Nothing here is confidential, and nothing here describes how specific decisions are made.

1. The problem domain

Digital advertising connects advertisers who want to show something with publishers and creators who have an audience. The software that connects them safely, prices the trade, moves money correctly and satisfies tax and financial regulation at every step is a large, unglamorous engineering undertaking. Most companies rebuild it before they get to the part that makes them different.

Start here: understand that the hard problems are settlement, verification and compliance, not targeting.

2. Acting as principal, and why it changes the architecture

A platform that acts as an intermediary routes money between two other parties. A platform that acts as principal buys in its own name and sells in its own name, takes title, prices each side independently, and carries delivery and margin risk itself.

The second model is harder to build and much harder to get wrong quietly. It forces the system to answer questions an intermediary can leave vague: what did we actually buy, what did we actually deliver, what do we actually owe, and can we prove each of those independently.

3. Insulation as an architectural property

Our two sides are insulated: no price discovered on one side sets a price on the other, and no customer’s money is traceable to any supplier’s payment.

The interesting part is that this is enforced in the schema and the service boundaries rather than in a policy document. A rule that lives only in a policy is a rule that survives until somebody is in a hurry. Think about what it takes to make a property like that structurally impossible to violate, and what it costs you in flexibility.

4. Transparent abstraction

Abstraction usually trades visibility for simplicity. We try not to make that trade.

Low-level complexity — allocation, queueing, routing, retries — is managed by the system. Workflows stay simple and adaptive for the people using them. And the underlying behaviour remains observable and controllable when somebody needs to audit it. Easy to say; the design work is in deciding exactly which seams stay visible and to whom.

5. Verification before value moves

Delivery is verified before anything is billed and before anybody is paid. That makes verification a load-bearing system rather than a reporting feature: it has to be accurate, timely, tamper-evident and cheap enough to run on everything.

Consider what that means for a live video stream, where the thing you are verifying happened once, in real time, on somebody else’s machine.

6. Privacy as a structural property

Blowtrumpet processes no viewer personal data. Creative is composited locally before broadcast, so there is no ad call — no tag, pixel, SDK, cookie, device identifier or viewer-side request. Targeting is contextual by counterparty: whose audience, never which individuals.

Note what this buys and what it costs. It removes an entire class of compliance risk and an entire class of attack surface. It also removes the easy answers to several measurement problems, which then have to be solved properly.

We are also precise about the claim’s boundary: we are a Data Fiduciary for creator and business-contact data under the Digital Personal Data Protection Act, 2023. Claiming “no personal data” would be a misrepresentation; the claim is no viewer personal data.

7. Scale, tenancy and siloing

Full tenant siloing: no tenant’s data, raw or derived, is exposed to any other tenant. Work through what that rules out — including several products that would otherwise be obvious to build — and you will understand most of our architectural decisions.

8. Gamification as a core domain

Keys, points, experience, reputation and levels are modelled as first-class domain concepts rather than bolted on. They are strictly non-financial: no monetary value, not convertible, not transferable. Designing a reward system that motivates without becoming a payment instrument is a genuinely interesting constraint problem.

9. The stack

Node.js and TypeScript. NestJS on the backend, Next.js on the frontends, containerised. Docker and OCI, orchestrated on infrastructure we run ourselves in India. Python where a specific workload earns it, and nowhere else.

10. How we think about engineering

Never resolve uncertainty by inventing an answer — open questions go on a register and get decided properly. A recommendation is not a decision until it is adopted. One home for every document. Stable identifiers that are never renumbered. Build-time enforcement of the rules that matter, because a rule nobody can break is worth more than a rule everybody agrees with.

Coming to an interview?

Read sections 2, 3 and 5 properly. We will ask you what you would do differently, and “I would build it the normal way” is a perfectly good answer if you can defend it.

[See open roles at Blowtrumpet]