O automatizare AI care funcționează perfect în demo poate deveni fragilă imediat ce intră în producție. API-ul modelului răspunde mai greu, CRM-ul este temporar indisponibil, două evenimente identice sosesc aproape simultan sau un document neașteptat blochează worker-ul.
Soluția nu este să legi serviciile printr-un lanț lung de request-uri HTTP și să speri că toate vor răspunde. Pentru fluxuri importante, o arhitectură event-driven, bazată pe cozi și procesare asincronă, separă producerea evenimentului de executarea efectivă a taskului.
Un flux simplificat poate arăta astfel:
formular → eveniment → queue → worker AI → validare → CRM
Dacă AI-ul sau CRM-ul nu răspunde, evenimentul nu trebuie pierdut și nici procesat la infinit.
Queue-ul devine tamponul dintre aplicație și AI
Să presupunem că un formular generează 500 de lead-uri într-o oră, iar pentru fiecare vrei clasificare AI, extragerea unor informații și actualizarea CRM-ului.
În loc ca formularul să aștepte răspunsul modelului, aplicația publică un mesaj într-o coadă:
lead.received
Mesajul ar trebui să conțină un identificator unic, timestamp, tipul evenimentului și referința către datele necesare procesării. Evită să introduci în queue cantități mari de date sensibile atunci când worker-ul le poate recupera ulterior din sistemul autorizat.
Worker-ele consumă mesajele în ritmul pe care infrastructura și API-ul AI îl pot suporta. Dacă volumul crește, poți scala numărul de consumatori fără să modifici formularul sau CRM-ul.
Servicii precum Amazon SQS folosesc inclusiv un „visibility timeout”: cât timp un worker procesează mesajul, acesta devine temporar invizibil pentru ceilalți consumatori. Dacă procesarea nu se finalizează, mesajul poate reapărea pentru o nouă încercare.
Retry doar pentru erorile care chiar merită reîncercate
Una dintre cele mai proaste implementări este:
„A apărut eroare? Mai încearcă.”
Un HTTP 429 provocat de rate limiting, un timeout de rețea sau un serviciu temporar indisponibil pot justifica retry. Un document invalid, un câmp obligatoriu lipsă sau un prompt care produce constant un output neacceptat nu se vor repara dacă rulezi aceeași operație de 30 de ori.
Pentru erorile tranzitorii folosește exponential backoff, de exemplu:
prima reîncercare după câteva secunde, următoarea după o perioadă mai mare, apoi din nou mai mult.
Google Pub/Sub permite configurarea retry-urilor cu exponential backoff, în locul redelivery-ului imediat. Azure Service Bus oferă, de asemenea, politici configurabile pentru retry și timeout.
Pune și o limită. Trei sau cinci încercări pot fi suficiente pentru multe fluxuri. Retry infinit înseamnă cost AI infinit, backlog și dificultăți de diagnosticare.
Folosește timeouts la mai multe niveluri
Un singur timeout global nu este suficient.
Ai nevoie de timeout pentru apelul către model, altul pentru operațiunea externă și o limită pentru întregul job. Dacă generarea AI ar trebui să dureze maximum 60 de secunde, nu lăsa worker-ul blocat zece minute.
Timeout-ul cozii trebuie corelat cu timpul real de procesare. Dacă mesajul devine din nou vizibil înainte ca primul worker să termine, doi consumatori pot începe aceeași sarcină.
De aceea, monitorizează timpul P95/P99 al taskurilor și setează timeout-urile pornind de la date reale, nu de la presupuneri.
Idempotency te protejează de dublarea acțiunilor
Sistemele distribuite trebuie proiectate presupunând că același eveniment poate apărea din nou. Amazon SQS Standard, de exemplu, folosește un model de livrare „at least once”, deci aplicația trebuie să poată tolera duplicate.
Fiecare eveniment ar trebui să aibă un event_id unic.
Înainte să creezi factura, să trimiți emailul sau să modifici CRM-ul, verifici dacă acel event_id a fost deja procesat. Dacă da, nu repeți efectul extern.
Această regulă este critică pentru AI agents. Un răspuns generat de două ori este doar un cost suplimentar. O rambursare, o comandă sau un email trimis de două ori poate deveni incident real.
Dead Letter Queue este locul unde ajung cazurile problematice
După numărul maxim de încercări, mesajul nu trebuie nici șters, nici lăsat să circule permanent. Îl muți într-o Dead Letter Queue – DLQ.
AWS, Google Cloud și Azure oferă mecanisme pentru izolarea mesajelor care nu pot fi procesate după mai multe încercări. Google Pub/Sub permite, de exemplu, configurarea unui număr maxim de tentative înainte ca mesajul să fie trimis către dead-letter topic.
În DLQ păstrează cel puțin: ID-ul evenimentului, numărul încercărilor, ultima eroare, momentul eșecului, tipul operației și correlation ID-ul fluxului.
Apoi investighezi cauza, corectezi problema și faci replay controlat al mesajelor. Nu goli automat DLQ-ul înapoi în producție fără să știi de ce au eșuat.
Observabilitatea trebuie proiectată odată cu workflow-ul
Pentru fiecare execuție loghează event_id, correlation_id, numărul tentativei, latența, serviciul apelat, modelul AI, rezultatul validării și starea finală. Pentru API-uri AI este util să păstrezi și identificatorii requesturilor furnizorului. OpenAI, de exemplu, recomandă logarea x-request-id și permite transmiterea unui X-Client-Request-Id propriu pentru depanarea requesturilor în producție.
Arhitectura matură nu urmărește doar câte joburi „au mers”. Urmărește backlog-ul, rata de retry, mesajele din DLQ, latența și costul per eveniment.
În producție, automatizarea AI robustă nu este cea care nu eșuează niciodată. Este cea care eșuează controlat, nu pierde evenimente, nu dublează acțiuni și îți arată exact ce trebuie reparat.
Surse folosite
Amazon Web Services – Amazon SQS Visibility Timeout și Dead-Letter Queues
Google Cloud – Pub/Sub Retry Policy și Dead-Letter Topics
Microsoft Learn – Azure Service Bus Timeouts, Retries și Dead-Letter Queue
OpenAI API Documentation – Debugging Requests și Request IDs
