David Cummings on Startups

Architecting an Infinitely Scalable B2B Web App

Written by

David Cummings

in

,

An entrepreneur was recently telling me how he was worried that his B2B web app might not scale if things took off. Of course, I explained to him that that would be a high class problem to have and that he shouldn’t worry about it. Focusing on finding product/market fit and customer acquisition is much more important. With that said, I did describe a simple approach to architecting an infinitely scalable B2B web app:

  • Round robin DNS to a handful of load balancers in separate data centers
  • Databases with near real-time replication between data centers
  • Separate databases for global information (like users, accounts) and limitless shards to hold account-specific information (multiple accounts per shard, when a shard gets too large it is split into two shards)

The benefit of most B2B web apps is that one account or user doesn’t need to know about another account, and thus the system can scale by adding more and more database shards horizontally with a global database that keeps tracks of what account is on what shard.

What else? What are your thoughts on this approach to an infinitely scalable B2B web app?

Comments

4 responses to “Architecting an Infinitely Scalable B2B Web App”

  1. Andrew Watson Avatar
    Andrew Watson

    For a lot of applications, critical data doesn’t need to be stored in a relation storage engine and can be stored in a “document” store like CouchDB which takes care of your replication concerns and shards.

    Usage of a caching system like a memcache or a Redis along with a message passing framework like 0mq can minimize pinch points as well.

    I’d suggest using AWS to host things as they give you the ability to create/destroy load balanced clusters of servers very easily. They also have memcache services, Elastic Map Reduce, Beanstalk, CloudWatch, Route 53 and more.

    Also, the first year of service on new accounts gets you a lot of free stuff!

    Reply
  2. Charles Brian Quinn Avatar
    Charles Brian Quinn

    When I think scaling a web application now-a-days, I think scaling all the other stuff like your development resources (people), your customers, your market, etc.

    I agree with you 100%. Scaling web applications with all the new cloud hosting providers is sometimes a slider away and costs cents on the dollar per month, whereas developers (and attaining new customers) costs much more.

    Reply
    1. Andrew Watson Avatar
      Andrew Watson

      The biggest problem with rapid adoption is… rapid adoption. If you don’t have a plan to support your new hard-won customers then you’ll start losing them pretty quickly. If you aren’t prepared to deal with their issues then be prepared to put out public relations firestorms and possibly thorny questions from your bank about chargebacks…

      Reply
  3. Stephen Reid (@smileysteve) Avatar
    Stephen Reid (@smileysteve)

    With virtualized (and cloud computing) servers any slightly expensive ($150+/mo) service should consider each account on its own set of vps servers.

    $10 for a cheap backup, and $20-$30 for the more powerful primary means that you can segment and scale as needed. Depending on your analysis and and market structures – you could even downscale the cloud instances during low usage times. And if one client needs more server power, it only take a minute and a datacenter switch to go to the maximum sized servers.

    Reply

Leave a reply to Andrew Watson Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

More posts