Architektura n8n i Make z modelami OpenAI, Claude i Gemini
Zbudowanie prostego webhooka łączącego CRM z API OpenAI działa bez zarzutu na 5 testowych kontaktach, ale zawodzi w nocy przy 50 zapytaniach w pętli. Brak obsługi błędów HTTP 429 (rate limits), timeoutów modeli oraz rotacji kluczy paraliżuje proces prospectingu i bezpowrotnie gubi wartościowe leady bez wiedzy zespołu.
Architektura produkcyjnego scenariusza opiera się na 4 filarach odporności na awarie:
| Warstwa | Ryzyko | Mechanizm obronny | Implementacja n8n / Make |
|---|---|---|---|
| 1. Rate Limiting | HTTP 429 (przekroczenie limitu TPM/RPM) | Exponential Backoff i kolejkowanie | Retry on Fail (3 próby: 15s, 60s, 180s) |
| 2. Model Fallback | HTTP 500 / 503 (awaria dostawcy LLM) | Multi-model routing | Switch z Claude 3.5 Sonnet na GPT-4o lub Gemini 1.5 Flash |
| 3. Bezpieczeństwo | Wyciek klucza w logach webhooka | Environment variables i Vault | Centralne n8n Credentials zamiast hardcode w URL |
| 4. Dead Letter Queue | Nieobsługiwany błąd parsowania | Izolacja rekordu i alert | Zapis do tabeli Airtable / bazy Postgres z powiadomieniem Slack |
- Skonfiguruj węzeł Error Trigger w n8n lub ścieżkę Error Handler w Make dla każdego zapytania HTTP do LLM.
- Ustaw limit współbieżności (concurrency limit) na maksymalnie 5 równoległych zapytań, aby uniknąć dławienia API dostawcy.
- Wdróż walidację odpowiedzi przed przekazaniem danych do CRM — jeśli odpowiedź modelu jest pusta lub uszkodzona, skieruj rekord do ścieżki re-evaluacji.
- ZŁY
- Bezpośrednie wywołanie węzła OpenAI w Make bez routera błędów. Gdy API OpenAI zwraca błąd 429 (Too Many Requests) o 23:00, cały scenariusz staje, a 40 leadów z kampanii przepada bez zapisu w CRM.
- DOBRY
- Implementacja n8n z Error Trigger i pętlą retry z opóźnieniem wykładniczym (3 próby). Przy trwałej awarii API następuje automatyczny switch na model zapasowy Gemini 1.5 Flash, a powiadomienie o incydencie z ID rekordu trafia na kanał #ops-alerts w Slacku.
Jesteś Senior Solution Architektem automatyzacji B2B. Kontekst: Projektuję scenariusz [MAKE / N8N] łączący [CRM: HubSpot/Pipedrive] z modelami [OpenAI / Anthropic Claude / Google Gemini]. Wolumen dzienny: [LICZBA LEADÓW — np. 250]. Typ operacji: [Enrichment / Klasyfikacja odpowiedzi / Drafting maili]. Zadanie: 1. Zaprojektuj architekturę przepływu danych z uwzględnieniem routera błędów (Error Handler). 2. Podaj dokładną konfigurację Exponential Backoff (liczba prób, interwały sekundowe) dla limitów Rate Limit (HTTP 429). 3. Zaproponuj schemat przełączania awaryjnego (Fallback Strategy): kiedy przełączyć ruch na model tańszy/szybszy i jak zapewnić spójność formatu odpowiedzi. 4. Określ strukturę rekordu dla Dead Letter Queue (DLQ) w Airtable/PostgreSQL, która pozwoli handlowcowi wznowić proces jednym kliknięciem. Zasady: - Zero twardego kodowania tokenów w nagłówkach HTTP. - Wymagany format wyjściowy: schemat logiczny (kroki 1-6) oraz przykładowy payload JSON dla alertu o awarii.
Warianty i alternatywne scenariusze
Wersja dla Make: użycie modułu Break i Routera z filtrem {{1.status = 429}}.
Wersja dla n8n Self-Hosted: kolejkowanie za pomocą Redis i węzłów RabbitMQ przy wolumenach powyżej 5 000 leadów dziennie.
Ćwiczenie praktyczne
Zaprojektuj w Make lub n8n prosty router awaryjny: skonfiguruj symulację błędu 429 na głównym modelu i zweryfikuj, czy scenariusz automatycznie przełącza zapytanie na model zapasowy i wysyła alert na Slacka.