Moonpig is an innovative billing and accounting system that I helped develop for a Philadelphia technology company between 2010 and 2012, totaling about twenty thousand lines of Perl. It was a success, and that is because we made a number of very smart decisions along the way, many of which weren't obviously smart at the time.
You don't want to hear about the billing and accounting end of Moonpig, so I will discuss that as little as possible, to establish a context for the clever technical designs we made. The rest of the talk is organized as a series of horrible problems and how we avoided, parried, or mitigated them:
Times and time zones suck
Floating-point arithmetic sucks
It sucks to fix your mangled data after an automated process fails
Testing a yearlong sequence of events sucks
It sucks to have your automated test accidentally send a bunch of bogus invoices to the customers
Rounding errors suck
Relational databases usually suck
Modeling objects in the RDB really really sucks
Perl's garbage collection sucks
OO inheritance sucks
Moonpig, however, does not suck.
Some of the things I'll talk about will include the design of our web API server and how it played an integral role in the system, our testing strategies, and our idiotically simple (but not simply idiotic) persistent storage solution.
Much of the design is reusable, and is encapsulated in modules that have been released under free software licenses.