Co wiemy?
**Scenariusz dydaktyczny (fikcyjny).** Nie jest relacją z konkretnego wdrożenia.
Projektujesz API przyjmujące płatności za zamówienia. Aplikacja wysyła żądanie `POST /payments`. Serwer przekazuje je do operatora płatności i zapisuje wynik. Czasem operator pobiera środki, ale odpowiedź do aplikacji ginie wskutek timeoutu. Aplikacja ponawia żądanie.
Zespół proponuje po prostu ponawiać każde żądanie po błędzie, a przed ponowieniem sprawdzać, czy zamówienie ma status „opłacone”. W pierwszych testach wszystko działa. W produkcji zdarzają się jednak dwa równoczesne żądania dla tego samego zamówienia oraz opóźnione potwierdzenia od operatora.
Jak zaprojektujesz ponowienia, żeby nie zainicjować drugiej płatności? Co zrobisz, gdy pierwsze wywołanie ma nieznany wynik?
Za co mentor ocenia odpowiedź?
Wynik jest wskazówką do nauki, nie oceną zawodowych kompetencji.
Zobacz pytania naprowadzające
- Czy odczyt statusu i wywołanie operatora są jedną operacją atomową?
- Jak rozpoznasz ponowienie tego samego żądania, a jak nową, świadomą próbę zapłaty?
- Czy operator wspiera klucz idempotencji i jak długo go przechowuje?
- Co zwrócisz klientowi, gdy operator pobrał środki, ale odpowiedź nie dotarła?