Jak zapewnić, że powtórzona wiadomość nie wykona skutku drugi raz?
Najpierw odpowiedz na głos lub w myślach, potem porównaj.
Odpowiedź
Ustalam identyfikator tej samej operacji i zapisuję, że już ją wykonano. Jeśli skutek i informację o wykonaniu trzymam w jednej bazie, powinny być zapisane razem w transakcji. Ograniczenie unikalności w bazie pomaga, gdy dwa programy próbują obsłużyć to samo zdarzenie naraz.
Zwykły zbiór ID w pamięci jednego serwera nie wystarczy po restarcie ani przy wielu serwerach. Zewnętrzna płatność jest trudniejsza: lokalna transakcja nie obejmuje obcego API. Potrzebny jest jego mechanizm ochrony przed powtórzeniem albo sprawdzenie, czy operacja już istnieje. Ten sam identyfikator z inną treścią powinien być traktowany jako konflikt.
Dlaczego to ważne: Praktyczne rozwinięcie idempotencji, ważne dla agentów wykonujących akcje.
Możliwe dopytania: Co po awarii między zapisem wyniku a potwierdzeniem kolejki?
Jak poszło? Bądź szczery — „Jeszcze nie” dodaje pytanie do powtórki.
Zacznij od
- D-P10 · Co to jest transakcja w bazie danych? — Backend, dane i system design
- D-P14 · Dlaczego wiadomość z kolejki może pojawić się drugi raz? — Backend, dane i system design
- D-P15 · Co to jest idempotencja? — Backend, dane i system design
Przećwicz w kodzie
- Znajdź błędy odbiorcy kolejki — samodzielna ocena z listą kontrolną
Dalsza lektura
- AWS: Using Lambda with Amazon SQS(otwiera się w nowej karcie)Docs; dostęp 22.10.2026. Polling, batch, duplikaty i partial batch response.
- PostgreSQL: Transaction Isolation(otwiera się w nowej karcie)Docs; dostęp 22.10.2026. Izolacja, blokady i serialization anomalies; dobra podstawa do pracy z ORM.