Advice on designing and building distributed application to track vehicles

Question

I'm working on application for tracking vehicles. There will be about 10k or more vehicles. Each will be sending ~250bytes in each minute. Data contains gps location and everything from CAN Bus (every data that we can read from vehicle computer and dashboard). Data are sent by GSM/GPRS (using UDP protocol). Estimated rows with this data per day is ~2000k.

I see there 3 main blocks (blocks -> mean main modules).

1. Multithreaded Socket Server (MSS) - I have it. MSS stores received data to the queue (using NServiceBus).

2. Rule Processor Server (RPS) - this is core of this system. This block is responsible for parsing received data, storing in the database, processing rules, sending messages to Notifier Server (this will be sending e-mails/sms texts).

Rule example. As I said earlier, received bytes there will be information about current speed. When speed will be above 120 then: show alert in web application for specified users, send e-mail, send sms text.

(There can be more than one instance of RPS on same machine).

3. Web application - allows reporting and defining rules by users, monitoring alerts, etc.

I'm looking for advice how to design communication between RPS and Web application.

Some questions:

• Should Web application and RPS have separated databases or one central database will be enough?

• I have one domain model in web application. If there will be one central database then can I use the same model (objects) on RPS? So, how to send changed rules to RPS?

I try to decouple this blocks as much as possible. I'm planning to create different instance of application for each client (each client will have separated database). One client will be have 10k vehicles, others only 100 vehicles.

Answer 1

You are pretty much there, since you are using NSB, you can subscribe to the Bus.Send you are already doing. From there you can string handlers together to create a rules pipeline. The last handler can be the one to save the state of the processing to your DB. If you want to decouple that processing from what is going on in the web app, you can create a separate DB from the web app and reporting that is read only. You can fire an event at the end of your processing to update this other DB. Check out Udi's Command Query Segregation posts on his blog.

Answer 2

It sounds like what you really want is CEP (Complex Event Processing). CEP systems watch a stream of events and use defined queries to capture certain occurences or sequence of occurences, and then react to them.

An open source option in .Net is NEsper.

Answer 3

You're trying to build a multi-tenant SaaS system that allows its users to configure it. For this, I wouldn't recommend using technical blocks as the top-level architectural pieces. Instead, look for more business oriented lines of decoupling - this may include a greater focus on the impact of time in your domain.

For example, from the time a user changes a rule, how quickly does it need to go into effect?

You may find that different rules have a different time-to-effect.

Find out why. Try to understand the business reasons behind why one group of rules needs to go into effect in under 5 seconds (for example safety), and others need to go into effect at the end of the month (for example billing).

This information will drive many architectural choices going forwards.

Although you will likely have the technical components you mentioned above used in the solution, how they get configured, which database they talk to, etc - all of that is driven by the different business contexts described above.

My recommendation is to go back and get more business insight before going forward.