asp.net high load sms/email scheduler architecture

Question

Can anyone answer me - How sms/email gate service works?

In General, i need asp.net mvc 3 web application, that should support high load sms/email api (on example, 100 - 500 requests to api per second). What architecture/algorithm should be used in this scenario?

My, i think wrong, solution (correct me pls, if it sucks) : 1) Many Http (or soap, or etc) requests to my service. Like "www.example.com/sms-api/send?blabla". 2) Inserting every request in db 3) Win service iterate all rows in db with status=NotInProcess (on example). 4) Proceed every item in a new thread (is it normal/correct?) and execute it (sending email, on example, with logging/waiting answer from another service etc).

I know, that should be exist any "best practice" to my question, but i didn't find it... Can anybody help my with my architecture question?

Answer 1

It's probably a bit more complex than just that, specifically with handling failures and what your full requirements are. I think once you define that, the architecture might be more clear. You're acting as an SMS/email gateway. That means whatever you're sending those messages through might have their own failures. What does that mean for your application? Are you yourself going to fail? Do you want to keep retrying sending?

If your external service fails, and you fail, then it's probably sufficient to just do a normal REST API with WCF (or ASP.NET MVC 4 and WebAPI ).

If you want to continually retry to send messages on behalf of your client, then you might want to look at something like Microsoft Azure Queues , along with a REST API in WCF (like above). When a client connects, you'll add the message to send to an Azure Queue, and use a thread (or worker role) to monitor new additions. What's advantageous about using a queue is you'll be able to process messages as they come, and it's durable. That means if your service goes down while trying to send messages, you won't lose any data in the queue. It gives you a bit more fault tolerance (assuming you implement it properly).

One thing you might want to look at too is Quartz.NET . This will let you schedule threads to be repeatedly executed on specific time schedules. This might be useful for a scaling retry mechanism. If your external service fails, try again in 1 minute. If it fails again, try again in 15 minutes (etc).

Answer 2

It depends on solution requirements.

Performance : If you exclude persistence you can save a lot of performance points. Because writing to DB is very expensive. Reading from DB is also expensive.

Scaleability : Dispatch all incoming messages to other host(s). At the beginning you can have these hosts on the same server (web), as your load raises you add additional servers and hosts on your side or use paid cloud service and dispatch messages in parallel. You can also dispatch messages to persistence and other required hosts (i believe you need authentication, authorization, billing etc.)

Availability : What if some host down? You need to restore incoming data and continue dispatching after host is alive.

Maintainability : You should be able to easily remove/replace/add new hosts, processing, higher/lower load etc.

Assuming all this I think very suitable architecture for your problem is SOA ( Service Oriented Architecture ). It can be based on MSMQ or RabbitMQ as transport and NServiceBus as framework. Read more here: http://particular.net/nservicebus