Attention, auctioned in milliseconds.
Every impression on the Bright Face Ads network is sold through a sealed, second-price OpenRTB auction, resolved in under 90 milliseconds, end to end, on a pipeline built with Scala, Python and Kafka.
- <0ms
- p95 latency
- 0+
- Auctions / day
- 0%
- Fill rate
Six stages, one budget: 90 milliseconds.
From the moment an impression appears to the instant the winning creative renders, here is everywhere the time goes.
01 · Bid request
An impression becomes available and a structured OpenRTB request is broadcast to demand.
02 · Enrichment
Geo, venue type, audience and floor signals are attached to the request.
03 · Auction
Demand partners respond; the engine runs a sealed second-price auction against the floor.
04 · Bid response
The winning bid returns with its creative markup and tracking URLs.
05 · Win notice
The winner is billed at second price and notified through the win URL.
06 · Render
The creative plays on the screen, in context, comfortably inside budget.
Second-price, sealed, and fair by design.
Every bidder submits one sealed bid above the floor. The highest bid wins, but pays just one cent more than the runner-up. Buyers never overpay, and publishers always clear at true market value.
- Hard price floors per slot, per deal and per buyer.
- Private marketplace (PMP) deals with guaranteed priority.
- Strict tmax timeouts, slow bidders are simply excluded.
- Transparent clearing: you always see what each impression was worth.
Google Ads bids highest at $6.70 but clears at $5.91, one cent over the runner-up.
An engine built to stay up and stay fast.
Requests stream through Kafka into a horizontally-partitioned bidder cluster written in Scala. Each shard runs auctions independently, so the system degrades gracefully under load and scales by adding partitions, not by slowing down.
- Scala
- Python
- Apache Kafka
- Kubernetes
- Partitioned
- Stateless
Exchange / SSP
Inbound OpenRTB requests over HTTPS.
Kafka ingest
Partitioned, replayable request streams.
Bidder cluster
Stateless Scala shards, auto-scaled.
Auction core
Sealed second-price clearing in-shard.
Response & logs
Bid response out; events to the lake.
Standards all the way down.
The exact shapes your DSP already speaks, OpenRTB 2.6 bid request in, bid response out.
POST /openrtb/2.6/bid HTTP/1.1
Authorization: Bearer <api_key>
{
"id": "8f2a91e0-…-e91",
"at": 2, // second-price
"tmax": 90, // ms budget
"cur": ["USD"],
"imp": [{
"id": "1",
"bidfloor": 4.50,
"video": {
"mimes": ["video/mp4"],
"minduration": 5,
"maxduration": 15,
"w": 1920, "h": 1080
}
}],
"dooh": {
"venuetype": ["transit"],
"geo": { "city": "Douala", "country": "CMR" }
}
}The numbers we hold ourselves to.
<90ms
p95 auction latency
End-to-end, request to response.
6.5M+
Auctions per day
Across the live network.
94%
Fill rate
Average across all slots.
99.9%
Uptime
Rolling 90-day availability.
What the bidding engine gives you.
Sub-90ms auctions
p95 bid response times that keep screens full and buyers competitive.
OpenRTB native
Standards-compliant bid requests and responses your DSP already speaks.
Fault tolerant
A resilient pipeline that degrades gracefully under load.
Built to scale
Millions of auctions a day, partitioned and streamed through Kafka.
Integrates with the stack you already run.
Standards-compliant interfaces mean most DSPs and exchanges connect with little to no custom work.
- OpenRTB 2.6
- VAST 4.x
- OpenRTB Native 1.2
- PMP / Deal IDs
- JSON over HTTPS
- OAuth2 bearer
Frequently asked questions
Yes, we implement OpenRTB 2.6 for bid requests, responses and win notifications, so integration with existing DSPs is straightforward.
