I appreciate all help and feedback. Parts bolded are critical parts if this is too verbose. Perhaps it will help to mention I am a green developer. I have found some useful info from related questions posted here and on Stack Overflow but nothing that felt 100%.
Background
Currently at work we are developing a web application with strict constraints set forth by the client. Normally we are a Rails shop, but the client really wanted to work with us. Thus to fit into their architecture we will be using ASP.NET. We are not very experienced with ASP.NET but some of the team including myself have used .NET for desktop applications.
This application is three tiered and includes:
- Public facing server(s)
- Web services server(s)
- Data server(s)
The client is expecting high demand and they may have multiple servers in any one of the tiers. There is a firewall between every tier. From my understanding this is a very common set up.
A core goal is to minimize trips over the wire from the public facing server to the database.
The Problem
How do we handle user authentication without hampering performance on an N-Tier application with potentially many servers at each layer?
What We’ve Done so Far
We toyed with the idea of using view state but ultimately felt like this would be a poor idea. Of course we are not opposed to re-visiting view state, but feel that view state offers no benefits over cookies and simply makes it harder for a user to have multiple tabs of our application open.
I have been exploring the path of using the default session state with a custom implemented session store. The default session state tends to generate multiple requests going over the wire. Logging in and out this is okay, but when the user is using the app we do not want this. The custom session store helps minimize impact, but not by enough.
Conclusion & Possible Idea
Since trips to the database will be inevitable on almost all requests once inside the application, perhaps giving the user a key on successful login is the best way to go. Then when the user requests a new page, or posts a new page we could send that key with the related SQL transaction for the request and validate the key. I believe this will simplify the code base immensely.
So to re-iterate the problem: How do we handle user authentication without hampering performance on an N-Tier application with potentially many servers at each layer? Does the idea above sound like a solid implementation?
Thanks,
Jonathon
1
Maybe I’m cynical but I smell a common problem here. They are expecting high demand and so are doing distributed everything from the get go with careful optimization. Before they have a product.
How do they know that they will get all of this traffic?
If they get all of this traffic, how do they know that something simple won’t scale?
The right solution is to implement a simple function that behind the scenes does a simple database request, but which later can be switched out for something fancy. And then don’t worry about it until there is a proven problem. A decade ago I did something similar, and we didn’t hit scaling problems until 100k dynamic pages/hour. And when we hit problems there, it wasn’t hitting the login that was the problem!
Yes, I could suggest lots of fancy architectures that scale better. I’ve built some as well. But until you need to go there, assume that you won’t.
5