API Rearchitecture Series – Breaking down barriers for more powerful platform

by Zach

This month, the Web Services team is embarking on a revolutionary change: a rearchitecture of how our platform operates. Upon completion, our clients will have access to powerful new features that will enable them to derive even greater value from building on top of our platform.

We want to share the details and experience of our technical development process. We’re currently working through the proof of concept phase and very soon will be developing our prototype. We believe the challenges we’re solving and the roadblocks we overcome are highly interesting and think others would be interested as well.

In the course of AppNexus’ short history, our two web service applications have undergone significant changes and expanded considerably. We started as a platform purely running PHP and connecting to a MySQL database. However, as our platform has grown in both transaction volumes and complexity, we’ve found it necessary to add several new technologies:

NodelJS – used to develop components for synching sessions between our datacenters

C – used for PHP extensions to accelerate common use cases

Memcached and Solr – used for caching to speed up data retrieval

Sphinx – used to increase search speed

Vertica – a database for reporting data storage

RabbitMQ – a system added to help move functions, such as transaction logging off of our critical path

Through all of these changes, it was clearly an evolutionary process, as each new component added or improved on a system that was still, fundamentally, a LAMP stack. With this new rearchitecture, we are basing our stack in JVM technologies, but allowing for components to be easily built atop it, which can be written in whatever language is best for the application.

The goal of our rearchitecture is to build a clean, powerful platform that pairs our own ease of development with powerful flexibility for our clients. During the rearchitecture, changes should be seamless. The only noticeable difference for our clients will be positive — marked improvements in response times and consistency.

From a technical aspect, the major change will be divorcing our CRUD logic from our higher level business logic. The search system, assembly of complex object hierarchies and several of our other more powerful features will happen in a separate application from the object retrieval and validation logic. Because of this, we’ll be able to spin up more powerful top-level applications feeding off of the same CRUD lowest layer. Our REST APIs won’t change too much, at first, but new applications will spring up quickly to take advantage of the new layered approach.

For our API clients, it may be some time before any of these changes require new integrations. However, we want to keep our clients apprised of the major changes ahead and how tools such as a powerful bulk query service will help them to take greater advantage of the AppNexus platform.

We hope to provide twice monthly blog posts written by members of our engineering team, as well as a monthly summary of our progress and decisions. So please, follow us over the next few months as we discuss and describe our work towards breaking our monolithic applications into a layered set up of loosely coupled systems.