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,125 | Comments: 45,490

filter by tags archive

Macto, a module features spec sheet for authentication

time to read 5 min | 997 words

imageI am going to talk about a few ways of trying to organize a project, mostly as a way to lay out the high level requirements for a feature or a module.

I consider filling in one of those to be the act of actually sitting down and thinking about the concrete design of the system. It is not final design, and it is not set in stone, but in general it forces me to think about things in a structured way.

It is not a very hard to do, so let us try to do this for the authentication part of the application. Authentication itself is a fairly simple task. In real corporate environment, I’ll probably need integration with Active Directory, but I think that we can do with simple username & pass in the sample.

Module: Authentication

Tasks: Authenticate users using name/pass combination

Integration: Publish notifications for changes to users

Scaling constraints:

Up to 100,000 users, with several million authentication calls per day.

Physical layout:

Since the system need to handle small amount of users, we have to separate deployment options, Centralized Service* and Localized Component*. Both options are going to be developed, to show both options.




authenticate user

Based on name & password
Lock a user if after 5 failed logins

less than 50 ms per authentication request 99.9% of the time, for 100 requests per second per server

create new user

User name, password, email

less than 250 ms per change password request 99.9% of the time, for 10 requests per second globally

change password


less than 250 ms per change password request 99.9% of the time, for 10 requests per second globally

reset password


less than 250 ms per change password request 99.9% of the time, for 10 requests per second globally

enable / disable user

disable / enable the option to login to the system

less than 250 ms per change password request 99.9% of the time, for 10 requests per second globally

You should note that while I don’t expect to have that many users in the system, or have to handle that load, for the purpose of the sample, I think it would be interesting to see how to deal with such requirements.

The implications of this spec sheet is that the system can handle about 8.5 million authentication requests per day, and about a 3/4 of a million user modifications requests.

There are a few important things to observe about the spec sheet. It is extremely high level, it provide no actual implementation semantics but it does provide a few key data items. First, we know what the expected data size and load are. Second, we know what the SLAs for those are.

* Centralized Service & Localized Component are two topics that I’ll talk about in the future.



Very promising!

Keep it coming.



Ayende, when you say "Integration: Publish notifications for changes to users", you mean event sourcing and pub / sub?

Can you also talk a little bit about what would be the baseline physical architecture for being able to support 100,000 concurrent users. What if it were to scale higher (maybe a million).

I ask as I want to understand what kind of memory, cpu, bandwidth and storage trade ofs and considerations you are making.



Ayende Rahien


Yes, pub / sub is involved, and is fairly important when you consider high scale optimization techniques (I'll touch on that when I'm dealing with the Localized Component part).

You question doesn't really have any meaningful answer, because it doesn't say what the system is doing.

For the authentication system, the number of 100,000 users was given to ensure big enough data size. Scaling it higher isn't particularily hard, just a big more disk space.

For the auth system, we don't care about concurrent users, we care about concurrent requests. Ideally, I want to be able to handle 100 requests per second per machine. That gives me about 20 ms per request (assuming dual proc machine).

That may not sound much, but it turn out to be 8,640,000 requests per day per machine.


Hi Ayende,

Do you plan to showcase S.O.L.I.D archietecture principals


I loved above presentation for its simplicity and concise nature.

It will be great if you can do same with MACTO.

Ayende Rahien


I am not sure that this would work, and I don't generally think SOLID when I work, but I'll see if it drops naturally.

Jake Scott

I know this is jumping the gun a bit but have you any plans to build this as a web application? I know of a really cool admin template that I think is free to use for non commercial applications. http://www.adminizio.com/template-views.php Download the lite version :) Would be cool if this app looked as good as it functions.



Krzysztof Kozmic


Let me guess, it just so happens that you are a developer of this admin template?


@ Krzysztof

Yeah no kidding. Jake go pawn your warez somewhere else.

Ayende Rahien

@Krzysztof & @Mr_Barf,

I am sorry, but I don't see a point to you comments.

Even if Jake is developing the templates, what is wrong with making a relevant request about that?


It's noise.


I am looking forward to see how will this evolve. When we talk about scalability, how will you test server load, so you will be sure that SLAs you specified are satisfied?


Let me guess, do your apps look like your name Barf? And no I didnt build those templates



See - noise. Nuffield said. Out.

Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - one day from now
  2. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 4 days from now
  3. The design of RavenDB 4.0: Voron has a one track mind - 5 days from now
  4. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 6 days from now
  5. The design of RavenDB 4.0: Separation of indexes and documents - 7 days from now

And 11 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    05 May 2016 - Physically segregating collections
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats