Katkat
Back

Design a high-throughput ad exchange

RokuBackend Engineer · Onsite
MediumBackend EngineerOnsiteSystem Design

Last updated

This problem tests your ability to design a low-latency, high-throughput distributed system capable of managing real-time bidding (RTB) auctions for streaming video advertisements.

Scenario

You are tasked with designing the backend for an ad exchange platform. The system must process bid requests from publishers (streaming apps) and conduct an auction among multiple Demand Side Platforms (DSPs). The system must respond to publishers within 50ms, with a total traffic load of 1 million requests per second.

Requirements

  1. Functional:
    • Accept bid requests (HTTP/gRPC) from publishers containing user context, device IDs, and content metadata.
    • Forward requests to relevant DSPs based on targeting criteria.
    • Conduct a second-price auction based on DSP bid responses.
    • Log auction results and billing data for offline processing.
  2. Non-Functional:
    • Latency: The total round-trip time for the exchange must remain under 50ms.
    • Scalability: System must handle 1M QPS.
    • Reliability: High availability with graceful degradation if a DSP is slow or unresponsive.

Discussion Points

  • API Design: Define the request/response schema between the publisher, exchange, and DSPs.
  • Architecture: Describe the services involved and how they interact (e.g., Gateways, Auctioneer, Cache layers).
  • Data Flow: How do you handle user profile lookups (e.g., frequency capping, segment targeting) with minimal latency?
  • Storage: How will you manage real-time bidding data vs. long-term historical logs?
  • Fault Tolerance: What strategies are used to prevent a single slow DSP from impacting the entire auction window?

Hints

Hint 1

Consider utilizing a high-performance in-memory key-value store (like Redis or Aerospike) for storing user profile segments to ensure sub-millisecond lookups.

Hint 2

Think about how to implement a 'circuit breaker' pattern or asynchronous bidding to prevent slow DSPs from blocking the entire auction pipeline.

Hint 3

Address the challenge of global distribution by partitioning traffic based on geographic proximity to reduce network overhead.

Follow-up questions

  • How would you ensure data consistency for budget pacing across multiple distributed auctioneer nodes?
  • If the traffic suddenly spikes by 5x, what automated scaling or request-shedding mechanisms would you implement?
  • How would you design the system to handle 'fraud detection' in real-time without exceeding the 50ms latency budget?