Skip to main content
Software Engineering

Return to Answer

added 253 characters in body
Source Link
jfriend00
jfriend00
  • 3.6k
  • 29
  • 18

This really depends upon how many devices you're trying to support and how often a transaction occurs with a given device and how much data is involved for a given device. Based on that, reasonable solutions range from using a file per device to persist the data waiting to be sent to the device up to a clustered regular database holding the data for each device and then up to high transaction, high scale queuing software.:

  1. Using a file per device to persist the data waiting to be sent to the device
  2. Using a clustered regular database holding the data for each device
  3. Using high transaction, high scale queuing software.

It also matters whether you will need to cluster your nodejs server to handle the load or not.

If you don't know right now that you have to go really high scale or how much load that scale leads to, then I'd be inclined to build an abstract class for the store (a class that could have any of the types of storage mechanisms mentioned above behind it) and initially put a "file per device implementation" behind the abstract store API. That "file per device" implementation can probably be built pretty quickly. You would just need a persistent ID to identify each device that you could then use in a filename.

Then, see how well that works and how well it scales and performs. Then, you only go to one of the more expensive solutions (to acquire, code, deploy and maintain) when you know you really need it. This builds the opportunity to scale more in the future into your architecture, but doesn't over invest in it now.

This really depends upon how many devices you're trying to support and how often a transaction occurs with a given device and how much data is involved for a given device. Based on that, reasonable solutions range from using a file per device to persist the data waiting to be sent to the device up to a clustered regular database holding the data for each device and then up to high transaction, high scale queuing software. It also matters whether you will need to cluster your nodejs server to handle the load.

If you don't know that you have to go really high scale, then I'd be inclined to build an abstract class for the store (a class that could have any of the types of storage mechanisms mentioned above behind it) and initially put a "file per device implementation" behind the abstract store API. Then, see how well that works and how well it scales and performs. Then, you only go to one of the more expensive solutions (to acquire, code and maintain) when you know you really need it. This builds the opportunity to scale more in the future into your architecture, but doesn't over invest in it now.

This really depends upon how many devices you're trying to support and how often a transaction occurs with a given device and how much data is involved for a given device. Based on that, reasonable solutions range from:

  1. Using a file per device to persist the data waiting to be sent to the device
  2. Using a clustered regular database holding the data for each device
  3. Using high transaction, high scale queuing software.

It also matters whether you will need to cluster your nodejs server to handle the load or not.

If you don't know right now that you have to go really high scale or how much load that scale leads to, then I'd be inclined to build an abstract class for the store (a class that could have any of the types of storage mechanisms mentioned above behind it) and initially put a "file per device implementation" behind the abstract store API. That "file per device" implementation can probably be built pretty quickly. You would just need a persistent ID to identify each device that you could then use in a filename.

Then, see how well that works and how well it scales and performs. Then, you only go to one of the more expensive solutions (to acquire, code, deploy and maintain) when you know you really need it. This builds the opportunity to scale more in the future into your architecture, but doesn't over invest in it now.

Source Link
jfriend00
jfriend00
  • 3.6k
  • 29
  • 18

This really depends upon how many devices you're trying to support and how often a transaction occurs with a given device and how much data is involved for a given device. Based on that, reasonable solutions range from using a file per device to persist the data waiting to be sent to the device up to a clustered regular database holding the data for each device and then up to high transaction, high scale queuing software. It also matters whether you will need to cluster your nodejs server to handle the load.

If you don't know that you have to go really high scale, then I'd be inclined to build an abstract class for the store (a class that could have any of the types of storage mechanisms mentioned above behind it) and initially put a "file per device implementation" behind the abstract store API. Then, see how well that works and how well it scales and performs. Then, you only go to one of the more expensive solutions (to acquire, code and maintain) when you know you really need it. This builds the opportunity to scale more in the future into your architecture, but doesn't over invest in it now.