Real time auction system

The type of system where good performance is a must, with no leeway!

More information

This was one of the more recent systems that I worked on in the org and one that caused quite a few challenges along the way. The idea behind it was that not only would it integrate with the other systems that were being developed, for scheduling auctions, but it would also provide real time auctions for hundreds of users.

What I did

I played a rather large role in ensuring that the performance remained good as the system scaled up, everything from introducing caching as necessary, to implementing queuing mechanisms to process all of the requests in a logical manner (given that auctions can be highly sequential in nature), WebSocket logic to alert users of business events quickly, in addition to lots of SQL optimization where necessary, to even things like implementing NTP algorithms to make the server time display client side accurately.

I was also responsible for eventually containerizing this application and gradual improvements to its architecture, in preparation for eventually splitting it up into microservices, should that be necessary because of further scalability requirements. And all of this happened with rather stringent requirements in regards to validations and business functionality, with plenty of rules that needed to be met every single time, to ensure that the transactions were conducted accurately and correctly.

What I learnt

It's always going to be easier to start with the design of a scalable system in mind, as opposed to trying to introduce that later down the line. However, it's also going to be slower to go about this approach, yet even so, in this particular case, knowing that the system would eventually have to scale upwards and possibly outwards, I wish that my colleagues had listened to me more and that we'd have gone for a queuing system from day 1. Regardless, I made it work and it was generally regarded as a success.