Azure scalable architecture design

Question

I need to design an AZURE architecture for a service. Some key features:

• the user load can reach up to 50K requests per second
• the architecture should be scalable
• the service requires real time user notifications
• some requests must be queued as there are limits for specific calls (user should know that an operation is pending)
• global availability

My first idea is:

• MVC as a client entry point (azure web site)
• WEB API as a backend (azure web site)
• Service Bus (for requests queueing)
• Web Jobs (workers for queued requests)
• Azure DB for data storage
• SignalR hub for live notifications
• Azure Traffic Manager

What do you think about the above? Any suggestions / best practices to make this highly scalable and available?

Answer 1

First of all, just to make sure: 50k requests per second? Are you sure that's not 50k concurrent users or some such? 50k/second is near Twitter volume. About a 1/10th of Google requests/sec volume - which is HUGE.
50k concurrent users usually translates to 500-600 requests/second (assuming 10 page views per 15-minute user session)

Now, onto your question: I would reconsider using Azure Service Bus for such a high volume system and consider Event Hubs (as Panagiotis pointed out) or stick with a simpler but more scalable Azure Storage Queues for messaging. You will need to design out a queue strategy where-by you will spread messages across multiple queues to not overflow single queues that live in single storage partitions.

I would also consider Azure Web Roles instead of Azure Websites to host IIS and to run queue processing. Websites are limited to 10 servers only per load-balanced endpoint. There are also limitations on the number of cores. With requests of 50k/sec you'll need a decent amount of horse power to run thru queues and serve traffic and 10 servers might not be enough.

Which Azure DB are you referring to? Azure Document DB? SQL Azure DB?