Custom Software Enables Auction Company to Scale to Over $2B in Sales per Year

The Client

NextLot is an online auction software company based out of Raleigh, North Carolina. They have been revolutionizing the way timed-online and live webcast auctions are being run for auctioneers. Their software is used by hundreds of auctioneers and has sold over $17 billion worth of lots through the platform.

Unlike auction software like eBay, NextLot is built specifically for auctioneers to support their existing services and processes throughout a live auction. The core features of the NextLot platform are a timed bidding system and a webcast that streams the auction live. Auctioneers also use the platform to manage their inventory, manage users, and invoice.

NextLot approached LaunchPad Lab (formerly Kohactive) to rebuild their legacy platform to correct malfunctions that were occurring due to the significant increase in traffic and usage.

The Challenge

Since its founding in 2007, NextLot has grown immensely. By 2013, they were hosting thousands of auctions, handling sales upwards of a quarter million lots and almost two million bids.

However, this type of scaling came with lots of technical challenges. Their servers couldn’t handle the overload of bids as lots closed, their webcasts began to time out as usage grew, and their platform was starting to cause transactional issues.

Many of the auctions in the NextLot platform were timed auctions. These are like a silent auction where all of the lots are listed, and bidders can place bets, and watch as the clock counts down. Sometimes timed auctions would last for a few days before their dramatic closing. Usually, traffic isn’t a problem until the end of the auction. As the lots closed, users would scramble to outbid each other and pre-set max bids would start to trigger across hundreds of lots automatically. The last hour of an auction would spike the load on the server by 100x, and sometimes we would even see over a thousand requests per second. In many instances, bids were dropped, and the servers struggled to stay up before eventually crashing.

Another important challenge for this project was the requirement to build a new, modern bidding interface. Since NextLot’s auction software is white-labeled, their customers needed a branded, customizable interface that they would drop into their websites. The previous solution was an iframe but our new challenge was to create a modern, javascript application that could be embedded with just a couple of lines of javascript. As part of the new bidding interface, we would require a new API architecture and backend system.

The issues were a mix of infrastructure and application services. Our goal was to examine the platform, build an auto-scaling system and rebuild the bidding interface to use caching and a better real-time system.

Approach

We had to create a robust scaling system to handle the elasticity of the product and support future growth. The first step was to migrate the platform to Amazon Web Services (AWS). We configured Elastic Beanstalk (EBS) to scale the servers up and down based on the traffic and throughput of the application. We also did some optimization of assets, added a CDN, and worked on horizontal scaling and database replication.

The next step was to build a more intelligent auto-scaling system that could react to auctions as they close. One of the biggest bottlenecks of the platform was the closing of hundreds of timed auctions within a short period. The client also needed a custom-built auto-scaler to address the huge spikes in traffic that frequently occurred.

Our system would recognize when an auction was closing and begin to scale up servers in anticipation of the load. Based on the number of registered bidders and lots, the auto-scaler would automatically spin up as many servers as was appropriate to handle the thousands of requests per second. If multiple auctions are closing at the same time, it would anticipate this and spin as many servers as needed. While the platform typically ran on four servers, it would scale up to 60+ servers to handle days when lots of simultaneous auctions were closing. After the auctions ended, the auto-scaler would scale everything back down.

The next step in building a platform that could scale was redesigning the bidding interface. The old interface was slow, clunky, and inefficient. We rebuilt the interface as a Single Page Application (SPA) using Ember.js and built a new backend API. The old interface used HTTP to update bids and would handle “real-time” through polling – which is checking for updates from the server on a timed basis. In the new interface, we used web sockets to create a true real-time connection between the browser and the server. As bids changed, it would immediately update the price on every browser connected to it. Using web sockets drastically reduce the load on the server since the browser wouldn’t have to ping for updates continually. The bidding interface was also built as a responsive web application, meaning that users could bid in real-time in their browser or mobile device. We saw a significant rise in mobile bidding throughout the next few years.

Moving the bidding system’s backend into an API architecture dramatically changed the speed and durability of the platform. Using Ember.js and an API reduced the server load times and page speed. To further improve performance, we created a caching layer into our API. This enabled the application to avoid inefficient queries and respond much quicker to cached results. The caching layer also improved the performance and speed of the bidding interface.