Consolidating what is in the comments.
Any decision has to go through loading tests and stress or actual use in production. It is no use to assume things. And you will have to redo these tests as you add functionality.
Anyway if you do not know what you are doing you will have problems regardless of the system you create and even the hardware you use.
This queue system for me is something weird. I think it’s barbering, I doubt what it would be necessary if I knew what you’re doing.
The Stack Exchange network you are using now has a lot of access and has no problems. They basically use the technology you want to use. Can Mongodb be better than SQL Server for your case? You know better than me.
I have my doubts if I should use Angularjs, I think there is a lot of use for fashion, but it would be just my opinion. I even think this will reduce the efforts needed on the server. But there are other good or bad implications.
Of course, at a certain point the solution is to add hardware. Horizontally or vertically. There is no way. And it comes out absurdly cheaper than implementing a complex software solution too complex to develop or support.
The biggest mistake I see in this statement is specifying which hardware to run on. The hardware should be sized according to the need, not keep changing the software to meet the hardware limitation, because this is not always possible. Even when it is, the option is the worst possible.
As you need it you can improve some things. But at first you would learn a lot about cache. Do it on several levels. This helps a lot to have scalability and even deal with some types of attack.
Of course, the design application can greatly influence performance. I’m not going to talk about this because there are no details that I can say anything appropriate, but I see a lot of software having performance issues because they were poorly designed (nor am I talking about poorly written code, which also causes problems). At some point you’ll have to think about whether you want a feature. There are things that would make this site much better than it is, but it doesn’t allow because it would greatly increase the processing cost. They chose performance over UX (although performance is also an aspect of UX). There are many websites that do this. Facebook and Google live making decisions like this. But remember that you are not Facebook.
What would be a queue system?
– Maniero
Similar to what some shopping sites do on black Friday. From a number X of accesses appears a message: "You are the number 10 of the queue, wait".
– Leandro Brito
Does this happen to navigate, to close the purchase, or what? I’m wondering why you need to do this. I would already reply beforehand that there is only one way to know. Test. Go doing and go doing load tests.
– Maniero
I agree. And regarding architecture, frameworks, bank etc, would you use something different? Mongodb for example
– Leandro Brito
That’s very specific, but I don’t think so. This site (or better yet, the OS) has an absurdly bigger traffic (and I think you’re being optimistic about this idea of 8k users/minute) and uses SQL Server and various levels of cache. Now this is important. See if there are any more details, I’ll put an answer that is not something specific, but I don’t think this can even answer, but it will be something not to be just in the comment.
– Maniero
I appreciate your help bigown. The question really is subjective, any advice or suggestion is welcome. I won’t worry about queuing initially, I’ll do the site and the load tests and if that points out a problem, I’ll think back to the queuing system.
– Leandro Brito