Ano kung ang isang pangyayari sa totoong mundo ay kailangang mag-trigger ng 10 iba’t ibang aksyon? Nakakatapos ang isang pagbabayad, dumating ang paghahatid, isara ang merkado, tapos na ang pag-verify ng customer Karaniwan, doon ay hindi natatapos ang proseso Isipin ang isang negosyo na natatanggap ang kumpirmasyon na nakakatapos na ang pagbabayad ng customer—maaaring kailanganin ng isang pangyayaring iyon na i-update ang order, i-reserve ang inventory, magbuo ng invoice, abisoan ang seller, simulan ang paghahatid, at i-update ang loob na sistema Ito ay isang pangyayari na naglilikha ng maraming susunod na aksyon At doon nagsisimula ang interesante na direksyon ng @RialoHQ na event-driven Sa halip na bawat application ay mag-check nang hiwalay kung nakarating na ang pagbabayad, maaaring magsimula ang workflow mula sa pangyayari mismo: Nakakatapos na ang pagbabayad → Natanggap ang pangyayari → Magsisimula ang mga kaugnay na workflow Mula doon, maaaring tumugon ang iba’t ibang bahagi ng application ayon sa kanilang sariling lohika: I-reserve ng sistema ng inventory ang produkto Nakakatanggap ng abiso ang seller Nagiging available ang paghahatid Lumilipat ang order sa susunod nitong estado Ang interesante hindi lang ang automation Ito ay ang koordinasyon Habang nagiging konektado ang mga application sa mas maraming API, serbisyo, at totoong mundo pangyayari, maaaring mag-impact ang isang pagbabago sa maraming bahagi ng sistema nang sabay-sabay Hindi dapat kailanganin ng isang pangyayari ang sampung iba’t ibang manual na tugon Ang mas magandang disenyo ay minsan ay simpleng: Nangyari ang isang bagay. Ngayon, hayaan na tumugon lahat na nakadepende dito.