Ask for System Design Advice: Monolithic vs. Modular Workflows for E-commerce Automation

Questions
1

Hi everyone, I’m building a rental automation system for an SME (estimating 50-150 orders/day) on a self-hosted n8n instance.

Currently, my setup is a single workflow handling two main processes:

  1. WhatsApp Auto-responder (Triggered by WAHA API)

  2. Booking Processing (Triggered by Tally Form Webhook → Postgres DB → Payment Gateway API to generate an invoice link).

(Attached: My current single-canvas workflow for context)
(Attached: My current single-canvas workflow for context)1920×1008 192 KB

Now, I need to add a new Webhook trigger to listen for successful payment callbacks from the payment gateway. I asked Gemini, and it suggested separating this payment listener into a new workflow (Modular approach). The reasoning was to improve workflow efficiency and prevent the Execution Logs from getting cluttered (especially separating crucial payment logs from spammy chat logs).

However, I often see community members sharing massive, complex workflows with multiple triggers on a single canvas.

From a system design and maintenance perspective for my expected load, is it better to separate the payment webhook into its own workflow, or is it perfectly fine to combine them all? What are the practical pros and cons regarding server performance and debugging?

Appreciate any insights from your real-world experiences!

Information n8n setup

  • n8n version: self-hosted v2.1.5
  • Database : postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via : VPS
  • Operating system: Ubuntu v22.04 LTS
3

Great question — this comes up a lot with growing n8n setups.

Short answer: Go modular. Here’s why:

1. Execution isolation
With 50-150 orders/day + WhatsApp traffic, a monolithic workflow means every WhatsApp ping creates logs mixed with payment processing. When something breaks at 2am, you want to filter payment executions instantly.

2. Error handling per concern
Payment failures need different retry logic than chat responses. With modular setup, you can set retryOnFail with specific backoff per workflow.

3. Memory and performance
Each execution loads the entire workflow. A 40-node monolithic workflow loads all nodes even when only the WhatsApp trigger fires.

Architecture I’d recommend:

  • Workflow 1: WhatsApp auto-responder (WAHA webhook)
  • Workflow 2: Booking processor (Tally → Postgres → Payment)
  • Workflow 3: Payment callback (webhook → status update → confirmation)

Use Execute Workflow node or shared Postgres tables to pass data between them.

Gemini gave you the right advice. Ship modular.

5

thank you so much for explain, bro

6

I see, so main objective is to avoid confusion during debugging if something happens. Thank you for the explanation and advice.