Workflow durabile cu Temporal și Inngest: alternative la cron jobs fragile
Cron jobs și job queues clasice de tip Bull, Sidekiq sau Celery au fost coloana vertebrală a procesării asincrone pentru un deceniu întreg. Au funcționat suficient de bine pentru sarcini scurte, idempotente și tolerante la eșec. Pentru fluxurile moderne de business, însă, încep să se vadă fisurile: cron-ul care nu rulează după un restart de mașină, job-ul care eșuează la pasul 7 din 10 și lasă datele într-o stare inconsistentă, retry-ul care duplică plăți.
Durable workflows reprezintă o schimbare de paradigmă. În loc să tratezi fiecare pas ca pe un task independent care trebuie să fie idempotent prin propriul efort, scrii codul ca un flow secvențial obișnuit, iar engine-ul garantează că execuția continuă de unde a rămas chiar și după restarts, deploy-uri sau căderi de infrastructură. Două platforme s-au impus în acest spațiu: Temporal, matur și open-source, și Inngest, modern, serverless-first și prietenos cu echipele de produs.
În acest articol analizăm când și de ce să folosești durable workflows, care sunt diferențele practice între Temporal și Inngest, cum modelezi sagas și retries idempotente, plus trei use cases reale unde echipa Blackbone a înlocuit cron jobs fragile cu workflow durabile, eliminând clase întregi de bug-uri.
01Problemele reale cu cron jobs și job queues clasice
Cron-ul tradițional are presupuneri implicite care nu mai sunt valide în arhitecturi cloud-native: că mașina rulează 24/7, că procesul nu este restart-uit în mijlocul execuției, că nu există două instanțe care să declanșeze același job în paralel. Într-un environment Kubernetes cu autoscaling, fiecare dintre aceste presupuneri pică zilnic.
Job queues de tip Bull sau Sidekiq rezolvă parțial: au persistență, retries și deduplication. Limita lor apare la fluxurile multi-pas. Dacă fluxul de onboarding al unui client are 8 pași și pasul 6 eșuează după pasul 5 care a făcut deja un side-effect tranzacțional, recovery-ul devine cod boilerplate complex pe care îl scrii în fiecare flux.
Costul real al acestor limite nu este vizibil la review-ul de cod. Apare la 3 dimineața când oncall-ul descoperă că 300 de clienți au primit factura de două ori sau că emailurile de welcome n-au plecat pentru ultimele 24 de ore din cauza unui restart prost cronometrat.
- →Cron jobs care nu se recuperează după restart
- →Job-uri care eșuează la mijloc fără compensare
- →Duplicări la retry pe operații non-idempotente
- →Lipsa vizibilității pe fluxuri multi-pas
- →Cod boilerplate de recovery în fiecare task
02Ce înseamnă durable execution și de ce schimbă jocul
Durable execution este un model în care engine-ul de workflow înregistrează fiecare pas executat și starea sa într-un store persistent. Dacă procesul moare după pasul 5, la repornire engine-ul citește istoricul și reia exact din pasul 6, fără să reexecute pasul 5. Această garanție elimină nevoia de a scrie manual logică de recovery pentru fiecare flux.
Modelul de programare pare magic la prima vedere: scrii cod secvențial obișnuit, cu await pe fiecare pas, iar engine-ul se ocupă de persistență, retries, timeouts și compensare. Sub capotă, runtime-ul interceptează apelurile către step-uri și le serializează în istoric. Codul tău devine determinist și replay-abil.
Marele câștig este în reducerea complexității. Un flux care în Bull cere 300 de linii de cod cu state management explicit, retries custom și compensări manuale, devine în Temporal sau Inngest 50 de linii care arată ca un script obișnuit. Echipa Blackbone măsoară frecvent reduceri de 4-6x în volumul codului de orchestrare.
În durable workflows, scrii orchestrarea ca pe o funcție async lungă. Engine-ul transformă această funcție într-o mașină de stare care supraviețuiește oricărei căderi.
03Temporal vs. Inngest: comparație practică
Temporal este matur, open-source, self-hostable și are SDK-uri în multe limbaje. Modelul său este puternic dar abrupt: trebuie să rulezi un cluster Temporal Server cu Cassandra sau Postgres, iar onboarding-ul echipei cere câteva săptămâni. În schimb, primești garanții ironclad, control total și un ecosistem de unelte mature pentru observabilitate.
Inngest este mai tânăr, serverless-first și optimizat pentru ergonomie developer. Modelul său funcționează splendid cu Next.js, Vercel și stack-uri TypeScript moderne. Onboarding-ul este de câteva ore, nu săptămâni, iar pricing-ul pe execuții este transparent. Pentru echipe mici și medii cu stack TypeScript, Inngest oferă cel mai bun raport timp-până-la-valoare.
Alegerea depinde de scală și control. Pentru fluxuri de zeci de milioane pe lună, regiuni multiple și cerințe stricte de auditare, Temporal self-hosted câștigă. Pentru echipe de produs care vor să livreze fluxuri durabile săptămâna asta fără să administreze infrastructură, Inngest este alegerea pragmatică.
04Modelarea sagas și a compensărilor
Sagas sunt patternul pentru tranzacții distribuite peste mai multe servicii. În loc de un commit atomic global, ai o secvență de pași locali, fiecare cu o operație de compensare care anulează efectul în caz de eșec ulterior. Durable workflows fac sagas naturale: scrii pașii ca apeluri secvențiale, iar compensările ca handlers de eroare la nivelul workflow-ului.
Exemplul clasic este onboarding-ul unui client care implică crearea contului, alocarea resurselor, configurarea integrărilor și emiterea facturii. Dacă pasul de facturare eșuează după ce primele trei pași au făcut side-effects, ai nevoie să dealocați resursele și să marchezi contul ca pending. În Temporal sau Inngest, această logică este explicită în 30-40 de linii de cod citibile, nu împrăștiată prin trei microservicii.
Compensările trebuie ele însele să fie idempotente și să tolereze eșecuri parțiale. Engine-ul le va re-rula dacă este necesar, iar codul lor trebuie să fie pregătit pentru asta. Aceasta este disciplina principală pe care echipa Blackbone o livrează la workshop-urile cu clienții.
- →Pași tranzacționali locali cu compensări explicite
- →Idempotency keys pe operațiile externe
- →Timeouts per pas și pe flux total
- →Audit trail automat al întregului flux
- →Reluare safe după deploy sau restart
05Trei use cases reale: onboarding, billing, fulfillment
Onboarding-ul de utilizator este cazul ideal pentru durable workflows. Un flux tipic include verificare email, configurare account, alocare resurse, trimitere welcome series, scheduling onboarding call. Fiecare pas are propriile sale eșecuri posibile. În cron, vei rescrie de la zero recovery-ul. În Inngest sau Temporal, fluxul rezistă la orice cădere și continuă automat.
Billing este al doilea caz unde durable workflows sunt aproape obligatorii. Procesul de generare factură include calcul subscripție, aplicare credite, taxare card, generare PDF, trimitere email, înregistrare în contabilitate. Un eșec la pasul 4 fără compensare înseamnă bani neîncasați sau, mai rău, taxări duplicate. Durable execution garantează exactly-once la nivel de business semantic.
Fulfillment în e-commerce este al treilea: rezervare stoc, autorizare plată, pregătire colet, generare AWB, trimitere notificare, închidere comandă. Etape multiple, fiecare cu un vendor extern care poate cădea. Echipa Blackbone a migrat astfel de fluxuri de la cron+queues la Inngest cu reducere de incidente de la zilnice la lunare.
06Migrare practică de la cron jobs la workflows durabile
Migrarea nu se face într-un singur sprint. Începi prin a identifica fluxurile critice și a le clasifica după impact business și frecvența incidentelor. Fluxurile de top intră primele pe roadmap-ul de migrare. Restul rămân pe stack-ul existent până când justifică investiția.
Pentru fiecare flux migrat, vei dubla temporar runtime-ul: vechiul cron continuă să ruleze, noul workflow rulează în paralel pe trafic shadow, iar tu compari outputs. După o săptămână de paritate, comuți traficul real și retragi vechiul cron. Acest pattern de migrare cu shadow traffic este crucial pentru a evita incidente la cutover.
Firma de IT Blackbone livrează aceste migrări în iterații de 2-3 săptămâni per flux critic, cu metrici clare de succes: rata de reușită end-to-end, p95 timp execuție, număr incidente per lună. Investiția se amortizează tipic în 3-6 luni prin reducerea muncii de oncall și a pierderilor cauzate de eșecuri tăcute.
Migrează întâi billing-ul, apoi fulfillment-ul, apoi onboarding-ul. În această ordine, ROI-ul este cel mai vizibil și cel mai rapid pentru CFO.
Concluzii
Durable workflows nu sunt o tehnologie de viitor, sunt deja standardul de facto pentru echipele care iau în serios fiabilitatea fluxurilor de business. Costul de a continua cu cron jobs fragile crește exponențial cu complexitatea produsului, iar la un anumit punct, fiecare incident dezvăluie cât de scumpă este în realitate datoria tehnică.
Recomandarea practică este să nu construiești noi fluxuri critice pe cron sau pe job queues clasice. Începe direct cu Temporal sau Inngest pentru orice flux multi-pas cu impact financiar. Costul de adoptare se plătește în prima lună prin codul mai puțin și incidentele evitate.
Vrei să elimini cron jobs fragile din produsul tău?
Echipa Blackbone proiectează și migrează fluxuri critice la durable workflows cu Temporal sau Inngest, cu shadow traffic și plan etapizat fără downtime.
Discută cu Blackbone