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: 18 | Comments: 79

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.


  1. Production postmortem: The industry at large - 7 hours from now
  2. The insidious cost of allocations - about one day from now
  3. Buffer allocation strategies: A possible solution - 4 days from now
  4. Buffer allocation strategies: Explaining the solution - 5 days from now
  5. Buffer allocation strategies: Bad usage patterns - 6 days from now

And 2 more posts are pending...

There are posts all the way to Sep 11, 2015


  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    01 Sep 2015 - The case of the lying configuration file
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats