Faster Bookmarks with Room to Grow
My team updated the MSDN and TechNet Bookmarks application eariler this week, and it's way faster and more reliable.
Bookmarks v1.0 shipped last month, and we've more than tripled the total volume of bookmarks that we collected in our 3 1/2 month beta. This is great news, but it also put a strain our previous architecture. Our goal for this most recent release was to increase the capacity of the system while making it faster and eliminating some bugs.
The simplest thing we did to increase capacity was to really optimize our business and database logic. By making every operation more efficient, we use fewer system resources for each request, and therefore increase the capacity of the system.
A nice side effect is that the app is way faster for users. For example, we updated our database layer (running on SQL Server 2008, of course) so that calls into it are 10-100x faster. This translates to much faster page load times, which makes Bookmarks a more useful solution and enjoyable experience.
A core focus of our recent release was increasing overall capacity of our bookmarking application. The growth in usage we've see was straining our old vertical database architecture, so we needed to rearchitect to allow inexpensive horizontal scaling.
We have a similar scale problem with our Forums app, and we are moving it to a partitioned (aka "sharded") architecture. This is expensive, however, since it requires that we isolate reads and writes for different forums to different clusters, while maintaining a centralized database for shared infomation.
Bookmarking is asymmetrical in that almost all queries to the database are reads. In fact, less than 1% of all requests writes to create or update bookmarks are tags.
We take advantage of this in our new DB architecture, and avoid the expense of partitioning/sharding, by moving all reads to a set of read-only database servers, while sending all writes to a centralized read-write DB cluster.
This solution was inexpensive to implement. In our business layer, we simply specified two SQL connection strings--one for reads and one for writes. We then rebuilt our database infrastructure to have a set of inexpensive read-only servers, and a robust read-write cluster. We added a SQL Remote Distributor to keep the read-only servers in sync with the read-write cluster.
The result is we can increase read capacity simply by adding more read-only servers. And since we have lots of room for growth on the read-write server, it will be a long time before we need to add capacity to it.
