W zderzeniu z realnym projektem, a nie dokumentacją.

Wiele systemów w healthtech i fintech ma ten sam problem: procesy, które nie kończą się w 15 minut. Wniosek czeka na decyzję compliance officera. Transakcja musi się cofnąć, bo downstream API padło. Onboarding użytkownika ciągnie się tygodniami. Do tej pory odpowiedzią były Step Functions, polling w bazie danych lub ciężkie serwisy orkiestracyjne. AWS Lambda Durable Functions, ogłoszone pod koniec 2025 roku, zmieniają to równanie.

Czym jest AWS Lambda i dlaczego to ważne przypomnienie

Lambda to usługa serverless, która uruchamia kod w odpowiedzi na zdarzenia w architekturze AWS. Uproszczona definicja, którą często powtarzam na onboardingach: Lambda to kod, który budzi się, robi swoje i się wyłącza. Nie martwisz się o skalowanie, czy obsługujesz jedno zapytanie czy milion, AWS dopasowuje liczbę wywołań bez twojego udziału.

Typowe zastosowania to przetwarzanie dokumentów po wrzuceniu do S3 bucketa, asynchroniczne przetwarzanie kolejek SQS (klasyk: nowe zamówienie wpada do kolejki, Lambda je obsługuje w tle) czy zy serverless REST API w architekturze API Gateway + Lambda, gdzie Lambda zastępuje tradycyjny serwer aplikacyjny.

Timeline tej usługi jest krótki, ale gęsty. W listopadzie 2014 AWS ogłosił Lambdę w preview na re:Invent. W 2018 SQS stało się natywnym źródłem zdarzeń i Lambda przestała być tylko backendem dla API. W 2022 przyszedł SnapStart eliminujący problem cold startu dla funkcji pisanych w Javie. I w grudniu 2025 na re:Invent – Durable Functions, które wyciągają Lambdę poza schemat „odpal i zapomnij”.

Na czym polega różnica: standardowa Lambda vs Lambda Durable

Standardowa Lambda nie trzyma stanu między wywołaniami. Jeśli coś ją przerwie tracisz postęp i zaczynasz od zera. Twardy limit wykonania to 15 minut.

Lambda Durable działa inaczej. Używa mechanizmu kontekstu (DurableContext), który zapisuje wynik każdego kroku. Przy wznowieniu platforma odtwarza kod od początku, ale zamiast wykonywać zakończone etapy ponownie podstawia ich zapisane wyniki z logu checkpointów i przeskakuje dalej. Nowe obliczenia zaczynają się tylko od pierwszego nieukończonego kroku.

To ma jeden kluczowy skutek praktyczny: Lambda Durable może przejść w stan uśpienia, czekać na sygnał zewnętrzny przez tygodnie lub miesiące, a potem wznowić się dokładnie tam, gdzie się zatrzymała. I co równie ważne dla ekonomii serverless — za czas, w którym Lambda Durable nie wykonuje kodu, nie płacisz za czas wykonania (compute). Dodatkowe koszty jak durable operations i storage checkpointów są w typowych workloadach pomijalnie małe, ponieważ dla stosunkowo krótkiej retencji i przy małych payloadach to ułamek procenta całkowitego kosztu tego rozwiązania.

Limit działania Lambda Durable: prawie rok.

Jak wygląda to w kodzie

Dwie zmiany względem standardowego handlera. Handler jest wrapowany przez withDurableExecution importowane z nowego SDK, dostępnego dla Pythona, JavaScriptu i Javy. Drugi argument handlera to DurableContext, który zarządza stanem między krokami i odpowiada za zapis wyników.

Saga pattern, cofanie kroków przy błędzie, niezbędne w transakcjach rozproszonych buduję bezpośrednio przez zagnieżdżone bloki try-catch. Blok catch wywołuje kroki kompensujące w odwrotnej kolejności. Logika biznesowa zostaje tam, gdzie powinna: w kodzie aplikacji, nie w osobnym pliku konfiguracyjnym.

Dla procesów wymagających ludzkiej decyzji lub odpowiedzi z zewnętrznego systemu pojawia się mechanizm callback ID i callback URL. Lambda generuje unikalny identyfikator zamrożonego wywołania (callback token) i punkt końcow (callback URL),, który zewnętrzny system musi trafić, żeby je wybudzić. Bez tego nie byłoby możliwości wznowienia konkretnego, oczekującego egzemplarza.

Działający przykład: semi-automatyczna akceptacja wniosków szkoleniowych z AI

Kilka tygodni temu byłem na AWS Summit Warsaw, gdzie Durable Functions były jednym z głównych tematów. Temat na tyle mnie zaintrygował, że postanowiłem zbudować POC i pokazać go na naszym wewnętrznym FireLab, cyklicznych spotkaniach, gdzie inżynierowie Fireup.pro prezentują technologie, które właśnie sprawdzają.

Wybrałem scenariusz, który łatwo przełożyć na realne przypadki: semi-automatyczny system obsługi wniosków szkoleniowych. Pracownik wrzuca wniosek do S3 bucketa. To triggeruje Lambda Durable, która przekazuje dokument do Amazon Bedrock z modelem Claude Sonnet 4.6. AI ocenia, na ile szkolenie pasuje do stanowiska wnioskodawcy, i zwraca wynik procentowy.

Logika decyzyjna jest trójpolowa: poniżej 50% – automatyczne odrzucenie, Lambda nie czeka, kontynuuje i zamyka sprawę. Powyżej 76% – automatyczna akceptacja, ten sam scenariusz. Problem leży w strefie szarej: 50–75%, gdzie model nie jest wystarczająco pewny, żeby działać samodzielnie.

Tutaj Lambda Durable zatrzymuje wykonanie. Generuje callback ID i callback URL, zapisuje stan i przechodzi w uśpienie – zasoby zwolnione, koszty zerowe. Dział HR dostaje powiadomienie, sprawdza wniosek i wywołuje endpoint sendSuccess lub sendFailure. Lambda budzi się dokładnie tam, gdzie się zatrzymała.

Domyślny timeout dla decyzji HR w tym POC to 72 godziny, ale można go ustawić na dowolny czas do roku. W demo wysłałem sześć fikcyjnych wniosków: hiring specialist, junior developer, kierowca, księgowa, marketing, senior developer. Pięć zamknęło się automatycznie. Jeden trafił do manualnego przeglądu i czekał w stanie running przez kilka minut prezentacji, aż ręcznie wysłałem zatwierdzenie. Lambda wróciła do życia, zatwierdziła wniosek, wynik wylądował w buckecie. Cały cykl widoczny w CloudWatch.

Ten wzorzec, AI jako pierwszy filtr, człowiek jako decydent dla przypadków niejednoznacznych, jest bezpośrednio przenaszalny na procesy kliniczne, underwriting w insurtechach czy workflow compliance w regulowanym środowisku fintech. Jeśli interesuje Cię, jak Fireup.pro projektuje podobne architektury dla klientów z sektora healthcare i finansów, napisz do nas bezpośrednio.

Lambda Durable vs Step Functions: kiedy co wybrać

Step Functions to dojrzałe, sprawdzone narzędzie. Mówię to bez ironii dla złożonych pipeline’ów obejmujących wiele serwisów, wymagających bogatej wizualizacji przepływów i niezależnej orkiestracji na poziomie infrastruktury, Step Functions nadal robi swoje.

Różnica jest strukturalna. Step Functions wymaga zdefiniowania przepływu jako osobny plik konfiguracyjny w formacie Amazon States Language, warstwa abstrakcji oddzielona od kodu aplikacji. Lambda Durable trzyma całą logikę orkiestracji wewnątrz funkcji. Jedna baza kodu, jeden deployment, jeden punkt prawdy.

Dla scenariuszy, gdzie orkiestracja jest nierozerwalnie spleciona z logiką domenową a tak jest w większości systemów, które buduję dla healthtech i fintech. Lambda Durable eliminuje narzut konfiguracyjny i utrzymuje spójność między tym, co widzisz w kodzie, a tym, co faktycznie się dzieje.

Podobną filozofię „logika w kodzie, nie w plikach konfiguracyjnych”  opisywaliśmy przy okazji projektowania złożonych workflow w artykule o podejściu projektowym vs procesowym w software development.

Gdzie to ma rzeczywiście sens dla produktów cyfrowych

Procesy compliance i approval to oczywisty przypadek: każdy wniosek, który musi przejść przez human-in-the-loop, decyzję compliance officera, podpis kliniki, weryfikację przez managera, bez Lambda Durable wymaga albo pollingu w bazie, albo osobnego serwisu do zarządzania stanem. Lambda Durable obsługuje to natywnie i bez kosztów za czas oczekiwania.

Saga pattern w transakcjach rozproszonych to kolejny scenariusz. Płatność trafia do procesora, aktualizacja konta czeka. Jeśli jeden krok się nie powiedzie, cofamy wszystkie poprzednie w odwrotnej kolejności przez zagnieżdżone bloki catch. Na AWS Summit Warsaw 2026 pokazywano dokładnie ten przykład: sklep online z cofaniem zamówienia przy nieudanej płatności.

Długotrwałe onboardingi w healthtech ciągną się tygodniami: weryfikacja tożsamości, zgody RODO, konfiguracja urządzenia przez klinikę, pierwsze wyniki. Lambda Durable pozwala modelować to jako jeden spójny flow zamiast wielu niezależnych zadań sklejanych zewnętrzną bazą stanów.