Κάθε ομάδα που παραδίδει ένα agentic σύστημα τελικά κάνει την ίδια ερώτηση, συνήθως γύρω στον τρίτο μήνα: «χρειαζόμαστε Temporal / Inngest / Restate, ή μπορούμε απλώς να προσθέσουμε retries;»
Η απάντηση είναι σχεδόν πάντα «χρειάζεστε τον durable orchestrator, αλλά για έναν λόγο που δεν είναι τα “retries”.»
Τι λύνουν στην πραγματικότητα τα retries
Τα retries είναι το σωστό εργαλείο όταν μια παροδική αποτυχία παρατηρείται από την ίδια διεργασία που έκανε την κλήση. Network blip, απόκριση rate-limit, ένα ασταθές downstream — ο caller έχει το αποτυχημένο αποτέλεσμα στα χέρια του, ξέρει τι προσπαθούσε να κάνει, και μπορεί απλώς να ξαναπροσπαθήσει.
Για αυτό χρειάζεστε: μια πολιτική retry με exponential backoff, ένα όριο μέγιστων προσπαθειών, και idempotency στον receiver. Αυτό είναι βιβλιοθήκη, όχι σύστημα. p-retry, tenacity, tokio-retry — διαλέξτε ένα και προχωρήστε.
Τι λύνει στην πραγματικότητα η durable execution
Η durable execution είναι το σωστό εργαλείο όταν η ίδια η διεργασία μπορεί να πεθάνει μεταξύ βημάτων. Crash, deploy, k8s που κάνει evict το pod, μια κλήση LLM 30 λεπτών που υπερβαίνει το request timeout σας — η ερώτηση δεν είναι «μπορούμε να ξαναπροσπαθήσουμε» αλλά «πού ήμασταν όταν έσβησαν τα φώτα, και πώς συνεχίζουμε χωρίς να επαναλάβουμε τα μέρη που ήδη πέτυχαν;»
Αυτό είναι θεμελιωδώς διαφορετικό πρόβλημα. Χρειάζεται:
- Persistent step state — ένα log των βημάτων που ολοκληρώθηκαν, με τα αποτελέσματά τους.
- Replayable history — όταν η διεργασία συνεχίζει, διατρέχει το log, παρακάμπτει τα ολοκληρωμένα βήματα, και συνεχίζει από το πρώτο ανολοκλήρωτο.
- Deterministic step boundaries — κώδικας δομημένος έτσι ώστε ο orchestrator να αναγνωρίζει τα βήματα ξεκάθαρα σε όλα τα replays.
Μπορείτε να γράψετε αυτό από το μηδέν. Άνθρωποι το κάνουν. Είναι έξι μήνες debugging race conditions πριν συνειδητοποιήσετε ότι χτίσατε μια χειρότερη εκδοχή του Temporal.
Η πραγματική απόφαση
Αν το agentic σας σύστημα έχει:
- Tool calls που διαρκούν πάνω από λίγα δευτερόλεπτα μεμονωμένα,
- Workflows με περισσότερα από ~3 διαδοχικά βήματα,
- Ένα handoff ή human-in-the-loop κάπου στη μέση,
- SLAs που δεν αντέχουν ένα restart deploy να προκαλέσει user-visible αποτυχία,
…χρειάζεστε έναν durable orchestrator. Όχι «ίσως θέλετε έναν για ωραία να έχετε». Χρειάζεστε έναν, και η μετέπειτα προσθήκη του θα είναι πολύ πιο ακριβή από το να ξεκινήσετε με αυτόν.
Αν το σύστημά σας είναι σύντομο, σύγχρονο, και stateless (ένα prompt, μία απόκριση, τελειωμένο σε 5 δευτερόλεπτα), τα retries είναι μια χαρά. Μην κάνετε over-engineering.
Τι παραδίδουμε
Στην πράξη, το προεπιλεγμένο μας είναι Temporal ή Restate (ανάλογα με το language stack), με τον κώδικα workflow δομημένο έτσι ώστε κάθε κλήση LLM, κάθε tool invocation, και κάθε έγκριση να είναι ξεχωριστό βήμα. Το κόστος είναι κάποια καμπύλη μάθησης και ένα runtime προς λειτουργία. Το όφελος είναι ότι το «τι γίνεται όταν αυτή η διεργασία κάνει crash στη μέση του workflow» παύει να είναι ερώτηση που πρέπει να απαντάμε για κάθε νέο feature — ο orchestrator την απαντά μία φορά.
Τα retries λύνουν το «αυτή η κλήση απέτυχε». Η durable execution λύνει το «αυτό το workflow πρέπει να επιβιώσει σε αποτυχίες του πράγματος που το τρέχει». Δεν είναι εναλλακτικές — τα περισσότερα production συστήματα χρειάζονται και τα δύο, και είναι το δεύτερο που οι άνθρωποι υποτιμούν.