How do we actually hit the 100ms latency window without the system locking up?

In a Real-Time Bidding (RTB) environment, if you take too long to respond, the ad exchange simply drops your bid. You aren't just fighting for the best price; you're fighting the clock. I've seen developers try to handle this with standard synchronous calls, and it's a recipe for disaster. Once your thread pool saturates, everything grinds to a halt.

The trick in Scala is to embrace a fully non-blocking pipeline. You want to treat the bid request as a stream of events. Instead of waiting for a database query to return the user's profile, you use a Future or a ZIO effect to trigger that fetch and move on. I usually recommend a "timeout-first" architecture: if the bidder doesn't find a winning price within 40-60ms, it should just return a "no bid" response rather than risking a timeout from the exchange.

case class BidRequest(id: String, imp: Impression, device: Device)
case class BidResponse(id: String, price: Double, adMarkup: String)

def processBid(request: BidRequest): Future[Option[BidResponse]] = {
  val timeout = 50.milliseconds
  
  // We wrap the bidding logic in a timeout to ensure we don't hang the exchange
  Future {
    val bid = calculateOptimalBid(request)
    Some(bid)
  }.timeout(timeout).recover {
    case _: TimeoutException => None // Better to bid nothing than to be too late
  }
}

How do we manage campaign budgets without creating a massive synchronization bottleneck?

This is where most RTB systems fall apart. You have a campaign with a $1,000 limit. If you have 10 nodes bidding simultaneously and they all check a central SQL database to see if there's money left, your database becomes the bottleneck. You'll spend more time waiting for locks than actually bidding.

I prefer a "budget slicing" approach. Instead of one global counter, you distribute "slices" of the budget to each bidding node. If a campaign has $1,000, give each of your 10 nodes $100. The node manages its slice locally in memory (using an AtomicLong or an Actor). When a node runs dry, it asks the central coordinator for another slice. This turns a thousand network calls into one call every few seconds.

class BudgetManager(campaignId: String, initialSlice: Long) {
  private val remainingBudget = new AtomicLong(initialSlice)

  def tryDeduct(amount: Long): Boolean = {
    var current = remainingBudget.get()
    while (current >= amount) {
      if (remainingBudget.compareAndSet(current, current - amount)) {
        return true
      }
      current = remainingBudget.get()
    }
    false
  }
}

What's the best way to handle the complex nested JSON of an OpenRTB request?

OpenRTB specs are huge. If you try to map every single field into a massive case class hierarchy, your code becomes unreadable and your serialization overhead spikes. I've found that the best approach is to be lazy. Don't map what you don't use.

Use a library like Circe, but instead of mapping the entire BidRequest, create small, focused "view" models. I often use Json.hcursor to dive straight into the specific fields—like the device IP or the site category—that my bidding logic actually cares about. It keeps the heap cleaner and makes the code much easier to maintain when the OpenRTB spec updates and adds twenty new fields you don't need.

Just remember: the faster you can turn that raw byte array into a Scala object, the more time your bidding algorithm has to actually make a smart decision.

📋 Practical Task

Implement the Budget Slice Refresh Mechanism

You have a BudgetManager that tracks a local slice of a campaign's budget. Currently, once the slice hits zero, the manager simply stops bidding. Your task is to implement a refreshSlice() method that asynchronously calls a mock CentralBudgetService to request another $100 slice of budget.

Requirements:

• Modify the BudgetManager to handle a "refilling" state so it doesn't fire off 1,000 requests to the central service while the first refresh is still pending.
• Ensure that if the CentralBudgetService returns 0 (campaign exhausted), the BudgetManager marks the campaign as permanently depleted.
• Use a Future or an async effect to ensure the refresh doesn't block the bidding thread.