Pete: Hey, it’s Pete. I’m here in New York.
And today we’re talking to Dag from Tapad. Dag’s the founder and VP of engineering. Thanks
for being with us, Dag. Dag: Thank you for coming.
Pete: So, first of all, tell us a little bit at a high level, what is Tapad? What do you
guys do? Dag: So, Tapad is a cross platform, or I’d
say multi-platform advertising company. We’re what’s called a demand-side platform, so our
customers are the actual advertisers, and they buy advertising through us. We’re in
what’s called the real time bidded space. This means that we are constantly processing
a lot of potential buy opportunities for ads, and we figure out in real time if you want
to buy an ad and how much you’re willing to pay for it.
And then we figure out which ad, or which banner, or whatever you want to place there.
And we do all this in real time. So it’s low latency high, throughput kind of business.
Pete: Okay. And tell me about the mobile aspect to your business.
Dag: So the mobile aspect is, there are, have been mobile ad networks for quite some time.
Which are fairly, maybe not unsophisticated, but the mobile space has been lagging behind
in terms of the progress that has been made on the online display space so, in the past
few years. So, especially, on the side of a real time bidding.
So we’re trying to bring some of the more sophisticated use cases, or uses of advertising
technology, to the mobile space. And we also allow customers to do cross-platform
targeting so you don’t have to go to one provider to buy mobile advertising, and to another
one to get the online display. We’re more a one-stop shop.
We do interesting things based on what people are doing on their mobiles. We can use that
for targeting them on their desktops and vice versus, which has started to resonate really
well with a lot of advertisers. Pete: Okay. So technically this means that
because you guys are doing real time bidding, there’s a high volume, low latency requirement
for your architecture. Is that correct? Dag: Yeah. So basically how it works, is that
whenever an app or mobile webpage or a traditional webpage is being served there can be multiple
ad units on the page or in that app. As the page is being rendered or as the application
loads pretty much, we have to make a decision or the whole network or the whole system has
to make a decision, which includes quite a few jumps from, let’s say, a mobile website.
They call an ad exchange, the ad exchange calls us and a number of other vendors or
demand-side platforms, and we all look at the data that we’re getting. We compare that
to the campaigns we’re running and we return basically a bid, saying, OK, this impression
is worth this much money to us. And all this has to happen before the user
actually notices because you don’t want to show a page with a lot of white blanks on
it, or on some sort of spinner, loading thing. So, the requirements are pretty, pretty strong.
You have to respond within typically 60 milliseconds and this includes network round trip time,
so the total processing time is very, very short.
And I mean there are companies that have higher volumes than we do in the online display space,
but we are currently processing about 25,000 requests per second on our servers.
Pete: And that’s one reason I heard that you guys actually made an interesting decision
to move off the cloud. Can you talk to us a little bit about that?
Dag: Yeah, I mean, we started out as a lot of companies on Amazon Cloud, and so the EC2
Cloud is excellent to get started. And makes it very cheap to start running a service.
Generally though, running on a public cloud where you have a lot of shared infrastructure
makes it hard for you to really find the hot spots, find what’s costing jitter in your
performance. So when you’re running on virtualized hardware,
you’re running on shared network infrastructure, you’re running on typically shared storage.
And we’re also, we’re a JVM shop, so we also have garbage collectors which add to the whole
mix. If you have too many moving parts it makes it really hard to pinpoint where are
our main sources of performance issues. Are they something we control or are they
in the actual infrastructure? And we realized that in many cases this was
actually in the infrastructure. I’m sure you can cope with that in many ways. To us being
able to respond on a timely basis, every single time is very important. So, to us the average
response time doesn’t really matter much. What matters to us is how many requests or
how many incoming requests are not handled within that very stringent time that we have
to process it. And if we are losing ten percent of all requests
we’re having a very high latency on our ninetieth percentile. That it actually might be ten
percent loss business for us. Because we cherry pick every single request and if we miss one
out of ten, that’s ten dollars, basically. The other factor is actually in terms of cost
we see that we can, when you start scaling up a little bit, start buying more specialized
hardware, more expensive hardware then very quickly you get a better performance ratio
with your own cloud. And we also have some hardware that you don’t even get in the cloud
at all. Like we’re using solid state discs for our
key value stores. And we also have some, on the analytic side, we have some very, very
high memory type hardware and memory, RAM is something that’s often very expensive in