Software Architecture


Optimal Auctions Software is written using well-established and industry-accepted free open source software. We take advantage of all the benefits of open source projects - massive testing and error-free software, as well as constant updates to make sure the software is always up-to-date against the latest bugs and threats to the system. We like to think that we are smart enough to know that we can take advantage of the amazing work of some software geniuses in the world and use the software that they have devoted so much time to.

Because we use free open source software, we aren't burdened with overhead costs that get passed on to our clients. Using free software allows us to keep our software cheap, and also allows us to focus all of our software development resources on improving and maintaining our auction software. We have followed the trend in software - take advantage of all the great software available for free and focus on what we do best - auctions.

Here is an overview of the architecture of the Optimal Auctions software and hardware solution, with details on each level below the diagram.

Optimal Auctions Software Netowrk Architecture


All users of the auction software, including bidders, administrators and observers, log in to our software using a web browser on their desktop, laptop, tablet, or mobile phone. We also offer Android apps and iOS apps for our larger clients. Our software is written to not only support the most recent browsers, but is backwards compatible with older browsers and operating systems to ensure that every bidder can access our software.

Additionally, our software will run perfectly in any browser with no plug-in and no external programs needed. Many of our competitors will require bidders to install extra software or configure their browser correctly in order to take part in an auction - this results in the auction administrators becoming the technical support for their bidders, forcing them to take on a role they not be prepared for. As we like to say at Optimal Auctions, "if you can buy something on Amazon, you can bid using our auction software".

The browser communicates with the web servers using maximum strength 256-bit SSL security. This level of security is even higher than most on-line banks, which typically only offer 128-bit or 156-bit security. SSL ensures that the data passing between a bidders browser and our web servers cannot be hijacked and cannot be ready by anyone. In other words, the data is fully encrypted from end-to-end.

Technical Details - our auction software on the client-side uses standard HTML5, CSS3, and JavaScript, particulary the jQuery library and AJAX. Our SSL is 256-bit AES encryption using Java Encryption.


A firewall is hardware or software that locks down servers, preventing access to the servers only via certain ports and even allowing access on those ports to only a few IP addresses. We have configured our firewall to have the strongest and most stringest security possible. Access to the web servers from the public is only allowed on ports 80 and 443, the standard HTTP and HTTPS ports. Access to the server itself via Remote Desktop or MySQL is limited to a white-list of IP addresses, where only the IP addresses in our office are whitelisted. This locks down the server to allow access only from our own employees.

Technical Details - depending on the auction setup, we use either a hardware based Cisco firewall or a software based Windows Firewall.

Load Balancer

A load balancer acts as a "divider of work" for servers, routing traffic evenly between all the available servers. In auctions that require horizontal scaling (more than one web server), a load balancer acts to evenly distribute the bidders between the multiple web servers and make sure neither servers gets too busy. The load balancer makes the entire system scalable.

In addition to evening the work load, a load balancer is smart enough to know when a web server becomes unavailable, and will route the work to the remaining servers. This allows the entire system to have a fail-over system in place for the web servers, whereby if one server fails, the entire auction can continue while maintaining scalability.

Not all auctions will require a load balancer - auctions with less than 300 bidders typically can be run on 1 web server, foregoing the need for a load balancer.

Technical Details - the load balancer runs Apache 2.2, which communicates with the Tomcat web servers via AJP.

Web Server

The web server does the majority of the work in the architecture. It's where all the software that runs the auction resides. It's the central hub around which the entire software runs. The web server runs an application server, in our case Tomcat 8. The application server is responsible for running an application, in our case Optimal Auctions.

The application server is responsible for receiving requests from bidders and routing them to our software properly. It's also responsible for communicating with the database and the cache as well, making sure both are in sync at all times. After gathering the data and resources necessary given the request from the bidder, it sends a result back to the bidder, which they see in their browser. All this happens in less than a second.

Typically our web servers can handle up to 300 bidders each. Any more than that, and the server becomes so busy taking requests from the bidders, that it doesn't have the resources to gather the data and respond in a timely manner. For that reason, once we get more than 300 bidders in an auction, we can add another web server to help handle the requests from bidders. Additionally, as we continue to add bidders, we can continue to add web servers. This is what is known as "horizontal scaling". We can keep adding web servers as we need them, and the load balancer will properly divide up the work to keep each one busy, but not too busy. So, less than 300 bidders we can stay with 1 web server, 350 bidders we would move to 2, and 2000 bidders, we can use 7 web servers in our architecture.

Finally, our software has been rewritten recently to take advantage of the modern hardware design, the hardware that runs our web servers. Modern hardware has a multi-core architecture. Multi-core basically means you can do more than 1 thing at the same time. These things run in parallel. Modern servers can have 8 cores or even 16. This means you can do 16 things at the same time. Our software has been rewritten to take full advantage of this new approach to computing, and we run all our intensive computations in parallel. Where our competitors may take a full minute to run a computation, our software can crunch the same numbers in 4 seconds.

Technical Details - web servers are run on Windows 2008 RC2, which have Java 1.8 installed. The application server is Tomcat 8, using 256-bit AES SSL connections.

Master and Slave Databases

We use the most popular enterprise level open source database available, MySQL. Every year we update our MySQL versions to ensure we have not only the fastest and most reliable database possible, but to ensure that we also have all the latest security features as well. Currently we are running MySQL 5.6, which offers superior read/write speed on a multi-core server.

We have recently set-up a master/slave approach to our databases. One server will be the main database, the master. This will be the primary database, the one the web servers communicate with and which will contain all the most up-to-date data. On another server, in a separate physical location, we have another server acting as the backup database, the slave. The slave will keep a copy of all the data in the backup database, as a backup and safety mechanism. The master database will ensure that all the data and indexes in the database match between master and slave in a background process. These syncs happen in fractions of a second, ensuring the both master and slave databases contain exact copies of the auction data.

Our database tables have been designed and optimized by database experts, to ensure top-level performance. We have optimized indexes on every table, and run InnoDB as our engine, ensuring that our databases have full ACID transaction support.

Technical Details - the databases run MySQL 5.6 with InnoDB table engines, with a giant buffer pool of 512 Mb.


One of the most recent innovations in high performance websites is also its most powerful - memcached. Though mainly only known by technical programmers, memcached is likely being used by every major website in the world. Memcached is an extremely quick data storage engine - up to 50x quicker than a DB. Websites, like ours, use memcached to store information that doesn't change ofen and needs to be read many times. Things like the products sold in an auction - these don't change once the auction starts, yet are loaded in nearly every page load. We store data like this in memcached, since it is so much faster than having to query this information from the database.

"If it's 50x faster, why use a database at all?" is a common question about memcached, but memcached is what's called "volatile". Meaning, it doesn't actually store the data anywhere that would survive the power going out. So, it obviously wouldn't work for a database, because who can afford to lose all your data if the power goes out? For this reason, we follow the common design pattern with memcached - check if it's available in memcached, and if it isn't, then query the database.

Technical Details - for our memcached provider, we use Couchbase 2.1 with a 256 Mb memcached bucket.