Steps 4–9 of Tubi's Advertising Pipeline: Pacing, Bid Collection, Video Transcoding, Bidding, Rendering, and Integration

Step 4: Pacing Control – Tubi uses Akka Actors and Akka Distributed Data (CRDTs) to track spend and budget, loading Spark‑generated spend forecasts and applying a simple control‑theory technique to decide whether an ad participates in the current auction.

Step 5: Bid Collection – Both direct‑sales inventory and programmatic DSP inventory are wrapped in Akka‑Stream flows that handle asynchronous network calls, concurrency limits, error handling, rate‑limiting, and circuit‑breaking, allowing the system to remain robust despite third‑party variability.

Step 6: Video Transcoding – Collected bids are examined for required video transcoding; if needed, videos are transcoded to ensure smooth playback across all Tubi apps, appropriate audio levels, correct content rating, and brand identification for reporting and frequency capping.

Step 7: Bidding – The core CPU‑bound auction solves a constrained optimization problem: an n × k matrix of bids (rows) versus ad slots (columns) with binary selections, subject to constraints such as one win per advertiser and at most one win per slot, maximizing revenue via linear programming.

Step 8: Rendering Results – Winning bids are rendered into the format required by each platform (e.g., VAST or JSON) using Akka‑HTTP templating to produce platform‑specific ad responses.

Step 9: Integration with Tubi – The entire ad stack, built with Scala, Akka, and gRPC, operates with sub‑10 ms SLA for 99% of requests, and the same technology underpins Tubi's machine‑learning and big‑data platforms, inviting engineers interested in distributed systems to join the team.