Kolejność zdarzeń

Informacja, że przesyłka dotarła, może przyjść do twojego systemu wcześniej niż ta, że ją wysłano. Zdarzenia pochodzą z różnych usług, przechodzą przez różne kolejki i po drodze są ponawiane, więc kolejność, w jakiej przychodzą, nie jest kolejnością, w jakiej się wydarzyły. Dowiesz się, jak to obsłużyć bez psucia danych, jak zauważyć, że brakuje zdarzenia, i gdzie kolejność da się naprawdę zagwarantować.

Pierwszy artykuł pokazuje, jak read model może przechować częściową informację, dopóki nie przyjdą brakujące zdarzenia. Drugi wyjaśnia, jak wykryć, że czegoś brakuje, gdy nie wiesz, czego się spodziewać. Trzeci dotyczy odkładania wiadomości z powrotem do kolejki w nadziei, że następnym razem się uda: kiedy to pomaga, a kiedy pogarsza sprawę. Ostatni wyjaśnia, jak brokery grupują i porządkują wiadomości i ile to kosztuje.

Czytaj po kolei.

  1. Dealing with Race Conditions in Event-Driven Architecture with Read Models

    2025-10-20My events came out of order! What should I do?! Are you familiar with the term “phantom record” and its benefits? No? Let me explain it to you today. Everyone has a plan…
  2. Handling Events Coming in an Unknown Order

    2025-11-03After the last article on Dealing with Race Conditions in Event-Driven Architecture with Read Models, I got such a question from Ben: You described the scenario where you…
  3. Requeuing Roulette in Event-Driven Architecture and Messaging

    2025-11-17I’m always saying that there’s a thin line between good and bad practice, and this thin line is named “Context”. That’s also true for the (anti-)pattern I’m calling…
  4. Ordering, Grouping and Consistency in Messaging systems

    2024-11-18We went quite far from our Queue Broker series in recent editions, but today, we’re back to it! Did you miss it? In an initial article, we introduced the QueueBroker—a…