Zunächst ein wenig Kontext: Ich bin kein IT-Profi. Ich arbeite in der Fertigung und habe mir das alles in meiner Freizeit aus Interesse selbst beigebracht — bitte gehen Sie also von keinem formalen Hintergrund aus, und halten Sie nicht zurück, wenn etwas naiv ist.
Ich habe ein kleines MES (Manufacturing Execution System) für eine Fabrik gebaut und möchte von Menschen, die n8n ernsthaft nutzen, eine ehrliche Realitätsprüfung, denn ich könnte es weit über seinen vorgesehenen Zweck hinaus einsetzen.
Die Einrichtung. Eine kleine Fabrik montiert Maschinen an Produktionslinien. Jede Einheit durchläuft 5 Abteilungen über 6 Linien. Es gibt etwa 30 Terminals auf dem Shopfloor (Kiosk-Browser), eines pro Arbeitsplatz.
Die Architektur. n8n ist das Zentrum von allem. Jede Seite, die Operatoren sehen, ist HTML, das in n8n-Code-Knoten generiert und über „Respond to Webhook
Hallo @Folpe77 Willkommen!
Der Ausführungsverlauf bricht zuerst zusammen, und das geschieht still und leise. Jeder Seitenaufruf und jede automatische Aktualisierung ist eine gespeicherte Webhook-Ausführung, also landen 30 Terminals, die alle 1 bis 3 Minuten aktualisiert werden, irgendwo zwischen 15.000 und 40.000 Ausführungen pro Tag gegenüber deinen ~40.000 Zustandsereignissen pro Jahr. EXECUTIONS_DATA_PRUNE_MAX_COUNT hat standardmäßig den Wert 10.000, daher wird das Protokoll mehrmals täglich überschrieben und die Zustandsänderungen, die du eigentlich nachverfolgen möchtest, sind innerhalb von Stunden weg.
Teilung nach Rolle statt Teilung des Frontends: Seitenrendering in eigenen Workflows mit „Erfolgreiche Produktionsausführungen speichern
Bei dieser Last kann n8n den Datenverkehr bewältigen, aber ich würde das aktuelle Vertrauensmodell für die Produktion nicht unverändert lassen.
Die Hauptrisiken sind nicht der reine Durchsatz; es sind Autorisierung, Parallelität und Wartbarkeit:
- Eine URL ist eine Bearer-Anmeldeinformation. Sie kann durch Browser-Verlauf, Screenshots, Logs, Referrer oder Lesezeichen preisgegeben werden. Verwenden Sie mindestens kurzlebige signierte Token, die an Terminal + Aktion gebunden sind, validieren Sie sie serverseitig und segmentieren Sie das Netzwerk. Verlassen Sie sich nie nur darauf, Schaltflächen zu verstecken – der Webhook muss jeden Zustandswechsel autorisieren.
- Machen Sie jede Zustandsänderung zu einer Transaktion in PostgreSQL. Aktualisieren Sie nur, wenn der aktuelle Zustand/die aktuelle Version mit dem übereinstimmt, was der Operator sah (optimistisches Sperren), und geben Sie dann einen Konflikt zurück, anstatt eine neuere Aktion stillschweigend zu überschreiben.
- Halten Sie Rendering-Workflows von Command-Workflows getrennt, wie Anshul vorgeschlagen hat. Deaktivieren Sie gespeicherte erfolgreiche Ausführungen für Lesevorgänge, behalten Sie fehlgeschlagene Ausführungen kurzzeitig bei und bewahren Sie Zustandsänderungsereignisse in einer dedizierten Audit-Tabelle auf, anstatt sich auf den n8n-Ausführungsverlauf zu verlassen.
- Platzieren Sie die Zustandsübergangsregeln in einem wiederverwendbaren Sub-Workflow oder einer Datenbankfunktion. Das Generieren von HTML über viele Code-Knoten wird das erste Wartbarkeitsproblem.
- Fügen Sie Integritätsprüfungen, Error-Workflows, Datenbankbackups und einen kleinen Abstimmungsjob hinzu, bevor Sie die Nutzung erweitern.
Ich würde ein funktionierendes System mit niedriger Last nicht sofort umschreiben. Ich würde zunächst die Autorisierung und transaktionale Schreibvorgänge absichern, Lese- und Command-Workflows isolieren und Latenz-/Fehlerraten instrumentieren. Ein separates Frontend wird sinnvoll, wenn UI-Iteration, Offline-Verhalten, umfassendere Authentifizierung oder mehrere Entwickler das eingebettete HTML schmerzhaft machen – nicht einfach nur, weil 30 Kioske zu viel für n8n sind.
**Der Ausführungsverlauf (Der „stille Killer
Der praktische Weg, dies zu entscheiden, besteht darin, einen kleinen „Production Drill
@Folpe77 dein 1–3 Minuten Auto-Refresh auf Übersichtsseiten ist selbst ein Skalierungsrisiko, unabhängig vom Execution Logging. Polling informiert Operatoren erst beim nächsten Refresh über eine Zustandsänderung. Wenn du also Zeilen hinzufügst, wirst du versucht sein, das Intervall zu verkürzen, was die Webhook-Last schnell vervielfacht. Ein billiger Fix, der kein komplettes Frontend-Rewrite erfordert: Weiterhin HTML von n8n servieren, aber Polling durch Server-Sent Events oder ein leichtgewichtiges WebSocket-Relay (sogar ein winziger separater Node-Prozess nur für Push) ersetzen, das n8n bei Zustandsänderungen auslöst. Terminals aktualisieren sich sofort und du reduzierst den meisten „Read"-Traffic, der n8n überhaupt trifft.
@Anshul_Namdev s Diagnose ist genau richtig — trenne das Seiten-Rendering von der State Machine, behalte die State Machine beim Speichern. Es lohnt sich, spezifisch zu sein, was das dir bringt: sobald diese History-Tabelle der echte Datensatz dessen ist, was auf dem Shop-Floor passiert ist, stellt sich die nächste Frage, ob etwas sie daran hindert, später stillschweigend bearbeitet zu werden — schlechte Migration, direkter DB-Zugriff, ein Bug irgendwo downstream. Eine einfache Tabelle deutet darauf hin, dass sie nicht angefasst wurde, beweist es aber nicht.
Getrennt davon, für die Genehmigungsseite deiner State Machine — Blockieren/Entsperren, Freigaben, was auch immer menschliches Eingreifen erfordert: es gibt ein Muster, bei dem eine Webhook-URL pro Workflow generiert wird, wenn er veröffentlicht wird, nicht pro Anfrage. Jedes Genehmigungsereignis für diesen Workflow landet auf derselben URL und startet eine frische Ausführung nur, wenn es tatsächlich ankommt, also nichts sitzt offen und wartet und nichts läuft Gefahr, mid-wait geprünt zu werden, wie Anshul beschrieb. Habe eine allgemeine Version davon gebaut — nicht KI-Agent-spezifisch, funktioniert genauso für eine menschlich gesteuerte State Machine wie deine. Teile ich gerne, wenn es nützlich ist