Bardzo fajna prezentacja! Uzupełniła moją wiedzę nt procesowonia wiadomości. Większość patternów już znałem: outbox pattern, czy jak zrobić impedentego konsumenta ale dla mnie inbox pattern jest mega ciekawym pomysłałem. Także procesowanie tych wiadomości ze store'a jest ciekawym konceptem jako subskrypcji na zapisie
Paweł, dzięki za feedback! Tak, inbox jest dużo mniej znanym wzorcem, ale bardzo pożytecznym. Przyjmijmy, że obsługujesz wiadomości (zdarzenia) z różnych modułów. Okazuje się, że masz błąd i chciałbyś przeprocesować zdarzenia jeszcze raz. Jeśli masz wiadomości (zdarzenia) zapisane w swojej bazie, to przeprocesowanie je ponownie, jest dużo łatwiejsze operacyjnie. Dodatkowo pozwala to nam na zmniejszenie wpływu "peaków" w ruchu, i procesować wiadomości w swoim tempie.
Może jako rozwinięcie całej tej architektury można by było poruszyć procesowanie takich wiadomości, kiedy używamy konwencjonalnej bazy danych jak postgres, niestety tam nie ma takich sprytnych mechanizmów jak subskrypcja na zapisie (wiem, że są triggery bazodanowe ale tutaj nie dadzą rady). I często kusi użycie cronjobow a jak wiadomo takie rozwiązanie ma dużo problemów, jak np. uruchomienie tego samego batcha jednocześnie na wielu instancjach czy procesowanie zbyt wielu wiadomości na raz.
Bardzo fajna prezentacja! Uzupełniła moją wiedzę nt procesowonia wiadomości. Większość patternów już znałem: outbox pattern, czy jak zrobić impedentego konsumenta ale dla mnie inbox pattern jest mega ciekawym pomysłałem. Także procesowanie tych wiadomości ze store'a jest ciekawym konceptem jako subskrypcji na zapisie
Paweł, dzięki za feedback! Tak, inbox jest dużo mniej znanym wzorcem, ale bardzo pożytecznym. Przyjmijmy, że obsługujesz wiadomości (zdarzenia) z różnych modułów. Okazuje się, że masz błąd i chciałbyś przeprocesować zdarzenia jeszcze raz. Jeśli masz wiadomości (zdarzenia) zapisane w swojej bazie, to przeprocesowanie je ponownie, jest dużo łatwiejsze operacyjnie. Dodatkowo pozwala to nam na zmniejszenie wpływu "peaków" w ruchu, i procesować wiadomości w swoim tempie.
Może jako rozwinięcie całej tej architektury można by było poruszyć procesowanie takich wiadomości, kiedy używamy konwencjonalnej bazy danych jak postgres, niestety tam nie ma takich sprytnych mechanizmów jak subskrypcja na zapisie (wiem, że są triggery bazodanowe ale tutaj nie dadzą rady). I często kusi użycie cronjobow a jak wiadomo takie rozwiązanie ma dużo problemów, jak np. uruchomienie tego samego batcha jednocześnie na wielu instancjach czy procesowanie zbyt wielu wiadomości na raz.