Best Practices for Designing and Building a Distributed Vehicle Tracking Application
I am working on a vehicle tracking application. There will be about 10 thousand cars or more. Each will send ~ 250 bytes per minute. The data contains gps location and everything from CAN Bus (all data that we can read from the car computer and dashboard). Data is sent via GSM / GPRS (using UDP protocol). Estimated lines with these data per day are ~ 2000 thousand.
I see 3 main blocks there (blocks -> main main modules).
1. Multithreaded Socket Server (MSS) - I have one. MSS saves the received data to a queue (using NServiceBus).
2. Rule Processor Server (RPS) is the core of this system. This block is responsible for analyzing the received data, storing it in the database, processing rules, sending messages to the Notifier Server (this will be sending e-mail / sms texts).
Example of a rule. As I said, the received bytes will contain information about the current speed. When the speed is above 120, then: show the alert in the web app for the specified users, send an email, send sms text.
(There can be multiple RPS instances on the same computer.)
3. Web Application - allows users to create reports and define rules, track alerts, etc.
I am looking for advice on how to create a link between RPS and a web application.
Some questions:
-
Should the web application and RPS share the databases, or would one central database be sufficient?
-
I have one domain model in a web application. If there is one central database, then can I use the same model (objects) in RPS? So how do you submit the changed rules to RPS?
I try to separate these blocks as much as possible. I am planning to create a separate instance of the application for each client (each client will have a split database). One client will have 10 thousand vehicles, while others - only 100 vehicles.
a source to share
You are trying to create a multitasking SaaS system that allows its users to customize it. For this, I would not recommend using technical blocks as top-level architectural elements. Instead, look for more business-oriented decoupling lines - this may include more emphasis on the impact of time in your domain.
For example, from the moment the user changed the rule, how quickly should it take effect?
You may find that different rules are different from time to time.
Find out why. Try to understand the business reasons why one group of rules should take effect in less than 5 seconds (for example, security), while others should take effect at the end of the month (for example, billing).
This information will lead to a lot of architectural decisions going forward.
Although you will likely have the technical components mentioned above being used in the solution, how are they configured, which database they communicate with, etc. - these are all related to the different business contexts described above.
My recommendation is to come back and get more information about the business before going forward.
a source to share
You are almost there, since you are using NSB you can subscribe to Bus.Send which you are already doing. From there, you can combine handlers to create a rule pipeline. The last handler can be the one that will save the processing state in your database. If you want to decouple this processing from what happens in the web application, you can create a separate database from the web application and read-only reports. You can fire an event at the end of processing to update this other DB. Check out the posts on splitting Udi Command request on my blog.
a source to share