Distributed SQL Summit Recap: How Admiral Scales Globally and Achieves Single Digit Latency
At the Distributed SQL Summit 2020, James Hartig – Co-Founder at Admiral, presented the talk “How Admiral Scales Globally with YugabyteDB on Google Cloud While Maintaining Single-Digit Latency.”
Admiral’s Go application runs in Google Cloud across 5 regions in 3 continents. This geo-distributed architecture is powered by a single YugabyteDB cluster that delivers an average global read latency of 3ms! In this talk, James walked us through how distributed SQL can be deployed on modern cloud infrastructure to provide a scalable, resilient, low latency, and fully consistent data service.
Helping online publishers sustain online content through relationships
Admiral helps online publishers engage with visitors through adblock recovery, paid subscriptions, privacy and consent management. As you can imagine, their dataset is large and complex. Because their previous NoSQL database had reached its limits in regards to scalability, they started to investigate distributed SQL as a possible solution. Over 16,000 publishers use Admiral’s platform and generate a combined 15,000 events per second.
Publishing is threatened by the phasing out of 3rd-party cookies
All the major browsers including Safari, Firefox, and Chrome have added tracking protection or will phase out third-party cookies entirely. This fact alone is expected to drop the ad revenue streams of some publishers by 50% unless they can figure out an alternative. Admiral’s solution to publishers is to provide a platform where they can build direct relationships with their visitors.
How to build relationships with users that generate revenue
Problem: Worldwide data availability
A first order problem that Admiral needed to solve was, “How can we provide single-digit millisecond reads from around the world?” Here’s a list of the requirements that whatever database they settled on had to meet:
Previous attempts: MongoDB and CockroachDB
So, what databases did they evaluate before settling on YugabyteDB? They started with MongoDB but it was deemed unsuitable because it scaled vertically or when they tried to scale it horizontally, it proved buggy and required too much operational overhead. Next they looked at CockroachDB, which did check the “horizontal scaling” checkbox, but to achieve the scale that Admiral needed, CockroachDB required too many instances, proved unstable at high CPU utilization, would become unavailable and did not support read replicas.
Solution: YugabyteDB deployed across 3 continents
After a thorough evaluation, Admiral chose YugabyteDB as it was able to deliver blazing fast performance with read-replicas and built-in balancing.
To learn more about Admiral’s deployment architecture, implementation details and performance numbers make sure to watch the video!
Want to see more?
Check out all the talks from this year’s Distributed SQL Summit including Pinterest, Mastercard, Comcast, Kroger, and more on our Vimeo channel.