Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

A question of Scale

time to read 2 min | 256 words

One of my routine set of questions when I am coming to a new codebase is: "What is the expected load on the system?" or "How big do you need this to scale?"

I have several variant of the question, including, "What precentage of your budget is dedicated for scaling scenarios?"

In plenty of cases, the answer that I get is vague. There is not definite scaling requirements, but the client want to be able to scale. Here are a few rule of thumbs that will help you to know if scaling is even an issue at this stage of the game.

  • If you can't came up with a number for the scaling scenario, you don't need to scale. A number isn't 10,321 concurrent connected users with a peak of 28,154 users. A number is "ten thousands to fifty thousands requests", "Fifteen million visitors a day", etc. You need to have an overall idea, otherwise, you don't need to scale.
  • If you are replacing an old (slow) system, and you don't know the numbers, you don't need to scale.
  • If you are planning of scale-as-we-go approach, but you don't have a way to measure usage (and usage is more than just requests per second), than you won't be able to scale.

Designing for scale has a cost associated with it, not a high one, if you are doing things correctly, but it is there. Be aware of unnecessary scaling efforts.


Jeff Tucker

I went to a good session on scaling web apps at devteach vancouver last year. The biggest take-away that I had from it is that scaling is NOT just about how long the server takes to handle a web request. You need to take into account the client-side compute time, the number of web requests your application makes, your bandwidth, the average size of each web request, how long it takes to go from the client to server (ping), and the number of concurrent requests the browser is able to make (hint: it defaults to 3). In order to measure your usage and figure out how to scale, you need to be able to measure all of these things.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats