No, as i said, we are using for event processing and for integrations, but always controlled by other means. We do not even use things like http trigger.
We have been on financial systems for 16 years, dont worry.
Our event streaming is NATS Jetstream, that supports Ack, Nack and also idempotent messages.
I'm sure there are many choices. I am familiar with Camunda which is more Java based and it backs up state to a database. The point was that by itself NR has no protection for loss of state. That is fine for things like home automation but not financial transactions. You can probably add things to it to make it safe, but it would probably not be the best starting point.
Yes, agree, I even made a separate tab for my home automation just to keep states updated and recoverable (using a MQTT broker on another computer in my network). I think this topic with state control will be even more important to handle when a team is collaborating in the same system
Really - i did not know that - but my understanding was (unlike the financial systems being discussed) - it was not meant to be a transactional system with a guaranteed completion (or back out) of writes ?
That is true of the simple filing system backed persistent variables. Of course, other types are possible too which might do more. But in principle, you are correct. In practice, for most uses of Node-RED, it makes little difference. But of course, you really do need to understand the limitations.
Full DB systems will use a transaction log to maintain safety even across multiple load-balancing instances. But even then, some interfaces might not be totally "safe". Depends on the DB and the client type. Many clients might cache data for efficiency.
Anyway, more to the point, you can have multiple instances of the file store, each with different settings, including one with a 0ms write-back. It will be quite impactful to your system (especially a Pi) if you try to write lots to it though.