OTTO develops its own Real Time Advertising technologies

When an advertisement is played out on a page on the Internet, there are basically two parties that have to come to an agreement. On one side is the marketer (supplier), who sells the advertising space for his client - the actual website. On the other side is the advertiser (demander), who wants to display his advertising on the space.

In the past, everything was simpler. The marketer sold quotas to the advertiser by phone and received a fax (or something like that) for confirmation. Today, advertising space is auctioned directly by marketers in real time. Ideally in such a way that visitors to a website are shown advertising that is relevant to them. Of course, everything is done in compliance with the GDPR.

The backend, i.e. the actual SSP, is the heart of the Orbidder. In its final stage, throughput is estimated to peak at about 50 thousand req/s. However, the load varies greatly throughout the day. At four o'clock in the morning, there is significantly less traffic on the German-speaking Internet than at 9 o'clock.

The main requirements for the backend are

• unrestricted and automatic scaling
• high streaming throughput
• fast response times (<< 1s incl. external calls to the DSP)
• high availability
• cost-efficient cloud design

These requirements seemed to us to be best solvable in the cloud with Kubernetes. At the start of the project, our impression was that other cloud providers were not yet as advanced with their managed Kubernetes solution, especially in Europe, as the corresponding alternative from Google Cloud Platform (GCP).

In addition to Google Kubernetes Engine (GKE), we use other services from GCP for post-processing or data storage, such as BigQuery and Google Cloud Storage. We set up the infrastructure with Terraform.

In our Kubernetes cluster, we deploy Ngnix as a reverse proxy and as the first point of contact within the cluster after the Google L4 load balancer. Ngnix forwards the HTTP requests to our SSP web server implemented in the Go programming language, which contains the bulk of the business logic.

After an egress call to our DSP service provider Active Agent, the SSP web server answers the respective requests. For monitoring, we use Prometheus and Grafana. For certificate management, we use the Kubernetes operator Cert-Manager, which automatically creates and regularly renews Let's Encrypt certificates for us.

Keeping an eye on costs

The last requirement, cost-efficient design, seems obvious at first. However, from our point of view, an explicit mention is nevertheless appropriate, since the Orbidder SSP backend is characterized by a very high number of events (BidRequests) per second with a comparatively low payload. Event-based streaming solutions are comparatively expensive with most cloud providers and are often not worthwhile with low payloads compared to services that are charged per GB or per single instance (such as a VM).

In addition, GCP has recently started offering two network variants. The Premium network, which is enabled by default, and the less expensive Standard network. The premium network has the advantage that it forwards international network traffic through the Google Cloud particularly quickly. For our service, which generates a lot of network load but mainly answers requests from Germany or Europe, the premium network offers no added value.

By using the standard network, we can save additional costs without any loss of quality.
Cloud costs are notoriously difficult to predict accurately. However, we estimate that our current setup is less than a tenth of the costs that would have been incurred by an implementation using, for example, Google Cloud Functions (analogous to AWS Lambda).

Conclusion and outlook

The Orbidder has been in live operation since May 2019 and is currently already responding to several thousand requests per second, e.g. from t-online.de or ebay-kleinanzeigen.de. More websites are being added continuously.
To improve our technological position, we plan to integrate our Orbidder SSP backend into a service mesh in the foreseeable future. Since we are currently in GKE, Istio as the service mesh preferred by Google is an obvious possibility.

From the use of a service mesh we expect better possibilities to observe and track processes within our cluster (observability), a fine-grained control of network traffic if required, a simple mutual encryption of all traffic within the cluster (mTLS), as well as many other comfort features that simplify the operation.

Currently, however, we are working at full speed on a solution that will also enable OTTO's partners to benefit from the advantages of the Orbidder. For this reason, we will not be tackling the construction of the Service Mesh immediately.