DevTalk #138 – O Event-Driven Architecture z Tomaszem Stolarczykiem

Czyli żeby tak na takim wyższym poziomie, za pomocą Logów w jakiejkolwiek postaci i móc powiedzieć, że ten event wyszedł z tej usługi i w tej innej usłudze spowodował to i to, że systemy o tym nie wiedzą, ale nad jeszcze jest jakaś warstwa, która o tym wszystkim wie, żeby potem zespół mógł zobaczyć, jaki jest dokładnie przepływ tych eventów, ich przyczyny i skutki. Dokładnie i to jest chyba też pierwszy taki, jeśli miałbym powiedzieć jakiś taki pierwszy bloker, czy że jeśli ktoś wewnętrznie tam w teamie myśli, że jednak tutaj Byśmy mogli zacząć trochę zabawę z eventami, właśnie event-driven architecture. No to jeśli nie będziecie mogli dostarczyć takiego jakiegoś monitoringu do tego, czyli faktycznie gdzieś tam nawet logów, ale takich, które gdzieś tam pokażą w tych metrykach, w tych dashboardach właśnie te correlation, causation ID,

To są te miejsca, gdzie ten event-driven, może nie full architecture, ale elementy gdzieś tam wrzucamy, bo nagle się okazuje, że biznes chce wiedzieć, ile było sprzedaży pół roku temu. Chcę wiedzieć, jak wyglądał system przed Black Friday 2023, a jak wyglądał po Black Friday 2023, dwa dni równo w południe. I to jest do tworzenia, nie ruszając jakichś logów, tylko po prostu z eventów. Dokładnie. To raz. Dwa, że na przykład zmienił mu się i chce jeszcze jakąś tam daną, no to wtedy też przebudowujesz ten lead model, bierzesz jeszcze z innego miejsca jakieś tam informacje na ten moment też historyczne i przedstawiasz to rozszerzone na przykład.