Hi @brunoripa, @tomazbracic colleague here.
- ) We are not trying to save the data for the whole trip on one single process, but only the lastest value of the device state, like location, notifications and so on, and because of that there is a must that we show the latest data to the users and not sending the notifications when two similar messages which can cause sending the messages twice and so on.
The pros of this(my opinion I don’t know if it is correct one) is know if the business logic was already processed by the event that comes before or if the user asks(website) for the device data he gets the latest data that was processed.
The cons you can have a slower processing time since the message needs to find the process on which he needs to send it to.
2.) No, for now, we only use one node and on that node, we can start the process when the new data comes in and leave it up until the device stops sending(we only use the process to hold the live data in, but all the rest we save on the NoSQL DB, at the end process is only responsible for sending the range of data that other process need to process this range for trips and other stuff).
The set up for now works, but when it comes to the distribution, there will be a few problems that probably this kind of set up will need to deal with(netsplits, upgrade of the system/business logic, so on). Now like @tomazbracic write we will need to scale up big time in the next few months are we were wondering if the current solution can be tweaked or there is any other suggestion or implementation on how to do the distribution.
