Pinboard - A Case Study For Simple Systems

by Ostatic Staff - Mar. 09, 2011

Back in December, Yahoo let slip that its popular bookmarking service, Delicious, was on the chopping block. Yahoo later recanted, but not before the service's users exited in droves searching out competing products. One such beneficiary of the "great Delicious exodus" was Pinboard, a small business run by Maciej Ceglowski and Peter Gadjokov. Maciej recently posted details about what it was like to havesite traffic grow exponentially overnight, and described the business model and system architecture that allowed them to do it.

Pinboard, as stated, is an online bookmarking service, similar to Delicious, with some great features thrown in. Unlike Delicious, Pinboard actually has a viable business plan. Some might even say that Pinboard is what Delicious would have grown into if the original service, del.icio.us (co-founded by Peter Gadjokov), had not been bought by Yahoo. Pinboard charges a one time signup fee, and for an additional annual fee offers the ability to download and store a copy of every bookmarked page, ensuring that even if the site you bookmarked disappears, your bookmark does not. Pinboard was trucking right along, and then this happened:


At the beginning of the tsunami of traffic, estimated at around 50 hits per second, the Pinboard site was run by three physical servers; one web server, one database server, and one server for background tasks and the MySQL slave. What I find most interesting about this setup is that Pinboard did attempt to cut corners by virtualizing its infrastructure. Virtualization is all the rage in the data center these days, finding its way into places where it's perfectly appropriate (Like domain or authentication servers), to places not so appropriate (like high-volume databases and indexing engines).

Simplicity and over-provisioning of hardware allowed Pinboard to thrive on the influx of traffic, and sound business decisions allowed the company to add more hardware to accommodate the additional load. If the site had instead decided to start out on a shared hosting or virtualization platform, its very likely that the first wave of traffic would have killed the server, pushing the traffic elsewhere.

In the open source datacenter, it is so easy for those of us who have knowledge of what is possible to over-engineer our solutions. We build frameworks and multiple layers of redundancy to take advantage of what is out there. What's possible, though, is often at odds with what we really want to accomplish. Like Pinboard, if what we are doing is running a web service, maybe the best thing we can do is take a step back and see if there are places we can simplify, instead of engineer. As an architect, administrator, or engineer, its always your responsibility to ask if you are solving the right problem.