Has anyone used n8n with traffic spikes?
Is there some documentation on the software architecture behind n8n? Will a request be pass through the whole workflow? Or are the requests decoupled from the processing?
I am wondering what will happen when a workflow is hit with e.g. 100 or even 1000 request/s. Of course I can test this myself but I thought I ask first how much real world usage n8n has gotten so far.
No there has been no load testing done. It is also quite hard as it would depend a lot on the hardware and even more on what exactly the workflow is doing. If you would like to do a lot of short running workflows I would advise to set EXECUTIONS_PROCESS=main
Because if that option gets set, it executes everything in the main process. If that does not get set, it creates (by default) a new process for every workflow execution and this has obviously much more overhead and the startup time increases a lot. From a few ms to like almost a second.
Here a related topic which talks about it:
The underlying architecture is more important than the hardware. The absolute numbers don’t matter. The information about the forking is exactly the kind of info I was looking for.
What also would be important to know is how the request/response time is dependant on the actual workflow. Is there some kind of back pressure on high loads?
These kind of things.
Not sure if anything is more important than the other. In the end is the throughput currently probably decided by a formula similar to:
[hardware] X [architecture] X [workflow] = [throughput]
So each of them can increase or decrease the throughput.
n8n is currently not optimized for high throughput at all or in any way. It does currently also simply not scale very well. Improving that and many other things and to make n8n generally enterprise-ready and able to be used in big deployments is one of the things which we will work on over the next months to a year.