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. 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 Kohactive to take over their legacy platform.
Since its founding in 2007, NextLot, they have grown immensely. By 2013 they were hosting thousands of auctions, handling the sales of over a quarter million lots and almost two million bids.
But the 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, sometimes we would see over a thousand requests per second. In many instances, bids were dropped, and the servers struggled to stay up before eventually crashing.
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 using caching and a better real-time system.
To scale the platform to fit the growing needs, we had to create a robust scaling system to handle the elasticity of the product. 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. Unfortunately, Amazon's auto-scaling system was too slow to react to these huge spikes in traffic.
Our team built a predictive auto-scaler to address this issue. 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 truly 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.
The infrastructure and bidding interface improvements had incredibly positive effects on the platform. Application downtime became a rare occurrence rather than a frequent event.
In 2015 alone, the platform handled more auctions, lots, and bids then all the previous years combined. By 2017, the system was handling over $2 billion in transactions and five million bids. The infrastructure became truly elastic, stretching from four to sixty server to handle the load – all without dropping any bids.
To scale NextLot up to handle billions of dollars in sales, we took on the following deliverables:
After the scale-up phase, we started to focus on refactoring old code and building new features into their growing platform. The scaling efforts continue to provide a robust foundation for continuous growth at NextLot.