Аккумулирование сообщений в N8N для эффективной работы с LLM

Main idea / problem

• When users send messages to an LLM-powered chatbot word-by-word or character-by-character, triggering an LLM response on every webhook event is inefficient.
• It can also produce many partial or incorrect replies.
• The video proposes an accumulation (debounce-like) mechanism in n8n:
  • collect all incoming user text arriving within a short window
  • send one combined message to the LLM
  • have the model answer once (“answer all questions at once”)

Demonstrated behavior (live test)

• The user sends multiple messages rapidly.
• In n8n, earlier workflow executions reach completion but effectively don’t respond (they “do nothing” because they are not the latest valid execution).
• The last execution successfully aggregates everything and returns a single combined response to the webhook.

Implementation details (technological concept)

1) Storage for accumulation: Redis

• Uses Redis as a fast in-memory store (cache-style) with a limited TTL.
• Stores:
  • the accumulated text
  • metadata identifying which n8n execution is the “current winner”

2) Key structure and uniqueness

• On each incoming webhook, the system uses:
  • user_id (unique per user/chat) as part of the Redis key (e.g., MSG_<user_id>) to prevent mixing messages across users.
• It also stores the workflow Execution ID in Redis metadata to coordinate concurrent workflow runs.

3) TTL (time window)

• When the first message for a user arrives, it is stored with an expire of ~30 seconds.
• This ensures Redis entries are automatically cleaned up and avoids buildup of old data.

4) Coordinating concurrent executions (the “winner” logic)

• Each incoming message triggers a new n8n workflow execution.
• The workflow delays for 10 seconds (“waiting node”), then decides whether to proceed.
• It compares:
  • the current workflow Execution ID
  • vs the Execution ID stored in Redis metadata
• If they match:
  • the workflow is the latest one (“winner”) and responds to the webhook with the final accumulated text.
• If they don’t match:
  • the execution is terminated/does nothing.

Why this works: during rapid typing, multiple executions start; each subsequent execution overwrites the “current execution” marker in Redis. After the wait, only the latest execution’s ID matches.

5) Handling message accumulation

• For the first message (Redis empty):
  • store the initial text under the user key.
• For subsequent messages (Redis already has data):
  • use an append operation to concatenate the new webhook text onto the previously stored text.
• The demo shows a combined result (e.g., two question marks separated by spaces).

6) Desync handling note

• The speaker notes that packets can sometimes arrive out of order or timing may desynchronize.
• They store timestamp metadata (with millisecond accuracy) and suggest that an additional time-order check could improve robustness.
• For now, the implementation keeps it simpler.

Workflow result / output

• After ~10 seconds of accumulation:
  • the “winning” execution reads the stored accumulated message from Redis
  • sends it as a single consolidated prompt (the webhook response in their test)
• After 30 seconds:
  • Redis keys expire automatically.

Review / guide tutorial aspect

• The video serves as a how-to guide for building an n8n workflow that accumulates rapid chat inputs before calling an LLM.
• It also mentions optional improvements:
  • better handling of out-of-order packets
  • potential alternative database approach (Redis is preferred for simplicity/performance)

Main sources / speakers

• Primary speaker: the video author (only source referenced; no named external guest or specific documentation source mentioned).