Obsługa błędów w strumieniach zdarzeń
Prędzej czy później zapiszesz błędne zdarzenie: bug źle policzy cenę, użytkownik zrobi coś, czego nikt nie przewidział, albo wiadomość przyjdzie dwa razy. W systemie, który przechowuje historię, nie wymazujesz pomyłki. Zapisujesz to, co ją koryguje, tak jak bank dodaje operację korygującą, zamiast poprawiać wyciąg z zeszłego miesiąca. Dowiesz się, jak to robić, żeby dane wróciły do porządku, a historia dalej pokazywała, co się stało.
Dwa pierwsze artykuły są krótkie i tłumaczą podejście: wysłanej wiadomości nie cofniesz, a „niemożliwy” przypadek i tak się zdarzy. Dwa kolejne pokazują w praktyce, na przykładach z hotelu, jak naprawiać bugi i zmieniać dane z przeszłości. Ostatni wyjaśnia, skąd biorą się zduplikowane wiadomości i gdzie można je odfiltrować.
Czytaj po kolei.

What texting your Ex has to do with Event-Driven Design?
2021-01-27We sometimes feel melancholic, blue and a bit messy. When we enhance those feelings with “gummy berry juice” then various dubious ideas come to our minds. We grab the…
No, it can never happen!
2022-01-05“No, it can never happen!”. Have you heard this sentence before? For example, a user with the same e-mail address may not register, or the shipment won’t be delivered. I…
Fixing bugs in Event Sourcing is hard, for real?
2026-07-27Every system ends up with bad data. Some of it comes from integrations, some from users doing things nobody predicted, and a good part of it comes from us, because we…
Oops I did it again, or how to update past data in Event Sourcing
2023-09-22One team win is a loss for the other. For some people, money loss is a gain for others. In the same way, the challenging parts of Event Sourcing are also its superpowers…
Deduplication in Distributed Systems: Myths, Realities, and Practical Solutions
2024-11-25Last week, we discussed how to use queuing to guarantee idempotency. What’s idempotency? It’s when we ensure that no matter how often we run the same operation, we’ll…