Penny auctions are a high intensity type of auction which always very close to ending, with a timer that keeps extending itself a few seconds every time someone places a bid, while dozens of users in each auction try to outbid each other at the last possible second. Because of this, penny auction sites have very strict performance and latency requirements. Also, all clients need be updated constantly, within less than a second, or they might miss the opportunity to bid on time.
When I was contracted to work on this project, there was already a basic live site, which wasn't working too well and was starting to have performance problems due to the growing traffic. The code at the time wasn't well structured and didn't lend itself to easy modifications, or to fast performance. Over time, piece by piece, that code was almost completely rewritten.
In the process I completely rewrote the polling mechanism on both client and server, leading to much faster performance, an enormous reduction in bandwidth, and a cooler server. In the end we were able to expand the maximum number of users connected simultaneously by 8x, while reducing server costs by 54%.
Besides the performance improvements, over time I added several new features to the site, most notably an "experience" system, to give rewards to high profile users of the site, automatic refunds for unhappy customers, and "multi-item" auctions, which allowed people to pick between several items after they won.
- Performance: The site runs in a single, pretty standard, virtual server with 2010 hardware. This server runs nginx, MySQL and memcached, and supports about 500 users at the same time, all polling twice a second, with CPU around 10%. There is plenty of margin for growth before this code needs to be revised.
- Memcached: The site relies heavily on memcached to be able to react fast. The amount of memoty that memcached is using is ridiculously low, however each item gets read an enormous number of times every second, making memcached crucial to performance. Absolutely all polling requests are processed without touching the database.
- Bandwidth: The polling is extremely efficient in terms of bandwidth. Users poll with only a specific ID assigned only to their window, and the server replies with only the information that has changed, making the typical response body about 70 bytes, in a homepage with 50 auctions that are constantly getting bid on.
- Transactions Handling: The codebase has successfully managed over 20 million dollars in transactions and keeps account balances for hundreds of thousands of users, dealing with several payment processors, automatic refunds, and hundreds of thousands of internal balance operations, bids, bets and payouts every day.
What the client said about my work
"Daniel is one of the best programmers that I've had the pleasure of working with in my more than 10 years of online business experience. He's smart, hard-working, and best of all truly cares in his heart about the quality of the product that he delivers.
We run a paid online service with a large cashflow, and the software was designed by Daniel to be incredibly efficient and deliver the quality our users have come to expect.
On one occasion, our server went down for external reasons. Even though it was late at night, Daniel responded within minutes and stuck around for hours to help solve our problem.
We chose Daniel because he had wide experience over a number of technologies, and on a follow-up phone call showed the enthusiasm that we knew would make the difference for us.
Daniel not only does the job fast, but he does it right. When other programmers glance through the code he's written, they're always amazed by its clarity and efficiency.
We are especially happy because his turnaround time is fast, he's great at communicating expectations, and he manages himself superbly well.
If you want a person to do the job right, I'd recommend Daniel Magliola for your project"
Back to Professional Portfolio