Głębiej
Semantyki dostarczenia opisują zachowanie przy awariach i retry:
- **At-most-once**: brak duplikatów, ale wiadomości mogą ginąć.
- **At-least-once**: (w założeniu) brak utraty, ale mogą pojawić się duplikaty.
- **Exactly-once**: brak utraty i brak duplikatów — bardzo trudne end-to-end, szczególnie z efektami ubocznymi.
Ponieważ retry i timeouty są nieuniknione, wiele systemów wybiera at-least-once i polega na **idempotentnych konsumentach**.
Jak robić idempotentnych konsumentów
- Dedup po id wiadomości (przechowuj przetworzone id z TTL).
- Idempotency keys dla komend (np. „obciąż kartę” z unikalnym kluczem).
- Constraints/upsert w DB, żeby ponowne przetworzenie było no-op.
- Outbox pattern do skoordynowania zapisu w DB i publikacji eventu.
Typowe pułapki
- „Exactly-once” w jednym komponencie nie gwarantuje exactly-once end-to-end.
- Efekty uboczne (mail, płatność) muszą być zabezpieczone idempotency key.
- Magazyn dedup może stać się hot spotem bez dobrego podziału/TTL