Throttling și rate limiting sunt două mecanisme prin care un furnizor de API controlează traficul, iar diferența practică este ce vede workflow-ul tău: o eroare 429 sau o întârziere. Indiferent de caz, furnizorul stabilește limita, iar tu controlezi ritmul cererilor, backoff-ul și plafoanele de reîncercare. Fără această disciplină, un vârf de erori oprește un flux altfel sănătos.

Un articol publicat de n8n pe 30.10.2026 explică exact această distincție și oferă câteva repere concrete pentru cine construiește automatizări cu agenți AI (sursa). În continuare nu traducem materialul, ci îl citim ca operatori: ce verifici, ce măsori, ce decizi.

Diferența care schimbă arhitectura, nu doar mesajul de eroare

Când un API permite 100 de cereri pe minut și tu trimiți a 101-a, reacția depinde de mecanismul impus de furnizor. La rate limiting, cererea poate fi respinsă cu 429 și workflow-ul tău trebuie să decidă singur când reia. La throttling, cererea poate fi pusă în coadă sau întârziată, deci nu primești eroare, ci latență. Concluzia de arhitectură: dacă tratezi ambele situații la fel, fie reintri prea agresiv, fie aștepți degeaba.

Pentru un flux care are pași dependenți, întârzierea nu este un detaliu cosmetic. Dacă pasul trei are nevoie de răspunsul de la pasul doi, o coadă de 40 de secunde la furnizor se propagă în tot lanțul. De aici prima întrebare de verificat: care este latența maximă acceptabilă pentru clientul tău și ce se întâmplă când furnizorul depășește acel prag.

Ferestre fixe, ferestre glisante, token bucket și leaky bucket

Modul în care furnizorul numără cererile contează mai mult decât cifra afișată în documentație. O fereastră fixă resetează contorul la fiecare interval, ceea ce permite vârfuri exact la graniță. O fereastră glisantă măsoară continuu ultimele 60 de secunde, deci așteptarea până la „minutul următor” nu îți redă automat tot bugetul de cereri.

Token bucket oferă spațiu de burst: tokenurile se acumulează în timp, iar dacă ai rezervă poți trimite mai multe cereri deodată fără să depășești limita. Leaky bucket face opusul, netezește traficul și transformă vârfurile în debit constant. Aceeași aplicație poate funcționa perfect pe un API cu token bucket și poate crăpa pe unul cu leaky bucket, cu aceleași cifre în documentație.

Recomandarea mea operațională: înainte să tunzi batch-uri și paralelism, citește secțiunea de rate limits a furnizorului. Nu presupune că toți premiază același tipar de trafic. O verificare incompletă a documentației nu dovedește că limita nu există, doar că nu ai găsit-o încă.

429, Retry-After și de ce backoff-ul fără jitter nu rezolvă problema

Eroarea 429 (Too Many Requests) este semnalul principal că ai depășit limita. Răspunsul poate include antetul Retry-After, care îți spune cât să aștepți. Regula simplă: dacă antetul există, îl respecți, nu ghicești. Dacă nu există, îți construiești propria strategie de spațiere.

Backoff exponențial înseamnă creșterea progresivă a pauzei după fiecare eșec: o secundă, două, patru, opt și așa mai departe. Fără un plafon de întârziere și fără un număr maxim de reîncercări, un incident temporar se transformă în buclă infinită. Ambele limite trebuie setate explicit, nu lăsate la latitudinea framework-ului.

Apoi apare problema la scară: mai multe workflow-uri care eșuează simultan vor reintra simultan, recreând vârful de trafic. Jitter-ul, adică o mică variație aleatoare adăugată fiecărei pauze, împrăștie reîncercările în timp. Fără jitter, backoff-ul exponențial produce în continuare sincronizare și spike-uri.

Ultima verificare, adesea sărită: cererea este sigură de repetat? Dacă are efecte secundare, o reîncercare automată poate executa acțiunea de două ori. Verifică dacă API-ul suportă idempotență înainte să activezi retry pe acel nod, nu după.

Cum arată disciplina asta într-un workflow real

Modelul pe care îl susține materialul n8n, și pe care îl consider corect, este simplu: previi întâi, repari apoi. Primul strat este pacing-ul, adică trimiterea cererilor în batch-uri cu intervale controlate, ca să nu atingi limita. Al doilea strat este retry cu pauză configurabilă, pentru 429-urile care apar oricum. Al treilea strat este un flux separat de eroare, care primește eșecurile persistente și le duce în log, alertă sau pași de recuperare.

Ordinea contează. Dacă sari direct la retry fără să paci cererile, tu compensezi o problemă de design cu reîncercări, iar costul apare în factură și în latență. Dacă adaugi doar batching fără retry, un singur 429 închide execuția. Ambele straturi sunt necesare, nu alternative.

Un detaliu practic pe care îl adaug ca recomandare, nu ca fapt din sursă: controlează concurența la nivel de platformă, nu doar la nivel de nod. Mai multe workflow-uri paralele care lovesc același API se adună. O limită globală de execuții simultane este adesea mai eficientă decât zece pauze locale.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă ai un magazin online și ai legat comenzi, stocuri, facturare sau raportare prin integrări API, ai deja acest risc în casă. Nu se manifestă spectaculos: apare ca un ordin care nu ajunge în ERP, un stoc actualizat cu întârziere sau un raport de dimineață care rulează de trei ori mai lent exact în ziua de vârf.

Trei lucruri concrete de cerut echipei sau furnizorului tău de automatizări. Unu: log pentru fiecare 429, cu timestamp, endpoint și durata de așteptare. Fără acest log nu ai cum să distingi o limită structurală de un incident. Doi: plafoane explicite de retry, cu alertă când sunt atinse, nu reîncercări tacite la nesfârșit. Trei: separarea fluxurilor critice, cele care ating banii sau comanda clientului, de cele necritice, cum ar fi rapoartele interne.

Un punct de onestitate: un audit automat care găsește multe erori 429 nu dovedește singur pierderi de bani sau efecte pe CPA. Dovedește că sistemul încearcă prea des. Verificarea corectă este măsurarea: câte cereri au eșuat, câte au fost reluate cu succes, care a fost latența totală pe flux. Când probele sunt insuficiente, recomandarea este să măsori, nu să declari o concluzie.

Pentru cei care lucrează cu agenți AI care apelează tool-uri, jitter-ul nu mai este opțional. Agenții tind să ruleze în paralel și să reîncerce la fel, deci corelația eșecurilor este ridicată. Aceeași disciplină de măsurare a citărilor din AI Search se aplică aici, vezi log-uri de server pentru AI Search: fără date despre cine intră și cât așteaptă, optimizezi pe intuiție.

FAQ

Care este diferența dintre throttling și rate limiting? Rate limiting impune un plafon de cereri pe perioadă și respinge surplusul, adesea cu 429. Throttling întârzie sau pune în coadă cererile peste ritmul permis. În ambele cazuri furnizorul controlează limita, iar tu controlezi răspunsul workflow-ului.

Trebuie să folosesc mereu backoff exponențial? Doar când API-ul nu oferă Retry-After. Dacă antetul există, îl respecți. Când lipsește, backoff exponențial cu jitter și cu plafon de întârziere și de încercări este varianta sănătoasă.

Pot reîncerca orice cerere? Nu. Verifică dacă cererea are efecte secundare și dacă API-ul suportă idempotență. O reîncercare oarbă poate duplica o acțiune, de la o comandă la o plată.

Arc: AI-ul ajută, decizia rămâne umană

AI-ul este bun la analiza logurilor, la identificarea tiparelor de 429 și la propunerea unor praguri de pacing. Poate sugera unde ai nevoie de jitter și care fluxuri ar trebui separate. Ce nu face este decizia de business: ce latență accepți, ce flux este critic, ce riști să duplici.

Execuția rămâne la media buyer și la omul care răspunde de sistem. El stabilește plafoanele, validează idempotența și decide când un 429 este zgomot și când este semnal. Iar pasul concret este simplu: pune pe masă logurile și pragurile. Aici intervine ALLSoft Agency, care transformă această discuție tehnică într-un plan verificabil, fără hype și fără cifre inventate.