Distributed Demand Side Platform

Case Study


• The client needed to bid on the traffic


• More than 10,000 tps per territory

• Campaigns must be controlled from a

central location

• Reporting must be centralized too

• Integration with major SSPs/exchanges

Project Description

  • Pic. 1 - Sharding Explained

    A compartmentalized deployment of a distributed system, i.e. groups of servers with identical purpose deployed in separate datacenters.

    DSP response time SLA: under 100ms

    DSP processing time: 10-30ms

    Maximum tolerated latency between SSP and DSP: 70-90ms

  • Pic. 2 - Shard Layout

    Each shard is integrated with one or more SSPs and exchanges that are geographically close to it to minimize latency

    All bidder instances are behind a load balancer.

    Distributed cache is used to maintain consistent state between bidder instances in a shard

    A distributed Message Bus is used to transmit control commands and raw events

    ClickHouse is used to store raw event data (i.e. impressions, clicks, auction results, etc.)

  • Pic. 3 - Distributed DSP Diagram

    Bidder instances are grouped into shards and are deployed close to the SSPs and exchanges in one or more territories

    One territory can be served by more than one shard

    Data is replicated between all the shards in a multi-master fashion with the help of ClickHouse

  • Key Takeaways

    Each shard can scale independently of others

    Other server roles can be extracted and scaled independently

    More than one shard can be deployed in one territory if needed

Let Us Contact You

  • Fill out the form below and we'll get in touch within 24 hours