The number of locations / time, as well as the way the location information is transmitted (is it TCP, UDP, etc) will help determine the optimal approach.
Some questions:
- How frequently do the 12000 devices send a message?
- How are the locations transmitted? UDP? TCP?
- What reliability requirements do you have?
From the sounds of it, having a service that can capture the requests and just maintain a queue internally of things to save to the database should work fine. I don't believe MSMQ will be of use to you unless you can change the transmission side, and even then, it may or may not be necessary.
EDIT: Given the comments below, I would suggest something where you have a TCP listener pass requests off to the threadpool to handle.
I would take a look at this tutorial about setting up a TCP listening server using the thread pool. The biggest potential problem I see is the number of requests - from what you're saying, you're going to have roughly 400 requests / second. This is going to be a bit of a challenge to handle without a pretty good system in place. The threadpool will probably perform better than trying to do your own threading, since you'll want to avoid the overhead of having to create new threads constantly. You'll definitely want to have very little delay in the main processing loop (like Sleep(0), or no sleep at all), since you'll have one request per 2.5 ms on average. A single Sleep tends to time slice at 14-15 ms minimum, so you probably won't want any sleep in the loop.
I would say, though, that you may find this doesn't work too well, since the raw amount of connections may be problematic. If there is any way you could convert to UDP packets being sent, it may get you better throughput (at the expense of some reliability).