Since BiliBid started, I’ve encountered and foreseen problems that may affect the experience of the bidders. I’ve done preventive measures to counter the problems I’ve identified.

As BiliBid continues to grow, I foresee new problems that may arise. Most of them are due to concurrency (users accessing the same resource at the same moment). I have to tweak and optimize my code and queries from time to time to make it as efficient as possible, while maintaining correctness.

Testing the changes is even harder. It’s hard to replicate a potential problem, since first and foremost it does not entail a single request only. It’s a combination of continuous requests (for the timer, messages, and bid history) and user-triggered requests (placing a bid) from multiple clients. At times, there’s no assurance that the changes I’ve made will prevent those problems from happening. What I do is just convince myself that the changes I’ve made were for the better. Once convinced, I deploy it to the production server and hope for the best.

Maintaining BiliBid is not as easy as it may seem. It requires attention especially during the first bidding night after changes were committed. I have to trust on my gut feeling to decide whether to rollback the changes or not.

On the lighter note, I see this strenuous task of maintaining BiliBid as a learning experience. I learned a lot from BiliBid alone. For the love of BiliBid, I’ve read a lot of articles on server hardening, tweaking database and web servers and other related stuff.