Use case feeback

Hi there,
I’m exploring n8n and trying to understand if this can fit my needs. Since this project appears to be amazing but huge, I’d love and appriciate hearing you feedback.

n8n will be deployed on kubernetes, using postgres as persistence layer. The deployment must be high available and fault tolerant, I suppose this can be easily achieved since I’ve seen that there’s a great community helm chart.

Here it comes the tricky part, I’ll try to be as clear as I can.

My goal is to be able to define a workflow like the following:

  • start the workflow based on time (cron-like) OR based on event, if the event could be received through kafka it would be the best, but it could also be an http/grpc trigger.
    • n8n-nodes-base.kafkaTrigger to start with and event?
    • n8n-nodes-base.cron time-based start?
    • n8n-nodes-base.webhook http call-based start?
  • make an http/grpc call (at the moment, but could also be a message sent over kafka)
    • n8n-nodes-base.httpRequest for http request, what about grpc? Do I need a custom node?
    • n8n-nodes-base.kafka to send a message over kafka?
  • wait for feedback/command execution result: this could be a matter of minutes, hours or even days. The “feedback” should be received through a kafka message, but in case this wouldn’t be possible, can be replaced with ad http/grpc call. That’s the part I really don’t know how to do, expecially if it can be done.
  • proceed making a new http/grpc call or producing a kafka message
  • wait again for the reusult
  • an so on…
  • each “wait action” must have a known timeout
  • if something fails, the workflow must be stopped and the error reported via http/grpc/kafka
  • each worflow must be created/deleted/managed programmatically (does n8n expose some APIs? I’ve only seen the CLI)

And last but not least: where is the how-to-use documentation of each node?

Thank you very much

Hey @FedeBev!

Welcome to the community!

Looks like you already have figured out most of the parts of the workflow. If a workflow involves waiting for some response from an external source (feedback in your case), I would break it down into smaller workflows. You can have a workflow that gets triggered when the feedback/command gets executed. You can use the Kafka Trigger node and the Webhook node that would listen for the feedback.

You can use the Error Trigger node that would trigger the error workflow. This workflow can use the HTTP Request node or the Kafka node to report the error.

You can find the documentation for the nodes at

Thanks @harshil1712 for your feedback!
I tought about that approch, but a see a big dowside: all my http nodes have to be followed by at least one “wait node”, many times 2 (command ack and command executed). Replacing each wait node with a trigger would lead into a lot of 2-nodes workflow, making the system really hard to control/debug/monitor/whatsoever.

What about a custom node? Should not be hard to write, but I don’t know how n8n would manage a long-runnig task, expecially if the replica which is holding the “wait process” goes down (this is more than a possibility since n8n will be managed by kubernetes). Will the interrupted workflow be resumed from where it left off?
Of course this problem doesn’t only concerns the wait-nodes, but they would be the biggest point of failure.

Hey @FedeBev,

I don’t have the correct answer to your question. My knowledge is limited here. I think @jan might be able to help you out here.