Fork me on GitHub
#architecture
<
2023-02-20
>
ehernacki15:02:23

Hello folks, I'm designing an application which is basically a collaboration workflow system (think of an issue tracker attached to file change events, with different actors having distinct roles in it), and I'm researching some architectural patterns to take into consideration. I'm currently evaluating the pros and cons of Event-Driven ones (e.g. Event Sourcing), and would appreciate if you could share others that I should also check out (not limited to Clojure though). Thanks!

Rupert (All Street)15:02:33

I've used Event Sourcing many times - particularly in Investment Banking tech. Here's my quick thoughts: Upsides • (A) Event sourcing makes if very cheap/trivial for any component to emit a message • (B) very cheap/trivial to subscribe and listen to events. • Visibility into the state of systems These are great and very empowering for teams. Downsides • However, (A) Means that you end up with lots of messages flying around that may or may not conform to any particular spec and may or may not be forwards or backwards compatible. It may also be overwhelming to piece together what went wrong (e.g. account balance is displaying incorrectly on screen - I now need to investigate 100s of events that could explain why). • (B) Means that you often end up with tight coupling because the details of a message from one component may impact many downstream components that all subscribed to the messages. • Batch updates/reprocessing (e.g correcting a typo in a field name)- can cause all downstream components to read and emit new data creating huge amounts of data and processing. • Components can just subscribe and emit events they cannot guarantee any responses and cannot easily cancel events. Event sourcing does not handle Request response particularly well - you end up having to build retries + timeouts + cancellation semantics from scratch on top of event sourcing and it would have really just been simpler to do a standard HTTP REST call in the first place. So overall Event sourcing is great when you are modelling workflows that are based on events and that are not particularly coordinated. In many/most other situations Request/Response is better (e.g. HTTP REST).

❤️ 4
ehernacki15:02:51

> So overall Event sourcing is great when you are modelling workflows that are based on events and that are not particularly coordinated. This is particularly my case... the workflow could also be represented via state machines, but what I'm wondering is what the alternative would be...

Rupert (All Street)15:02:11

State machine is particularly good when you have a single state value that can be enumerated and dispatched on. Database (SQL or NoSQL) would be another model - events modify rows in a database. Another is a stateful app that holds the data in memory (or backs up to disk/storage).

👍 2
ehernacki16:02:59

I see, thanks for your input!

Thomas Moerman18:02:56

I found https://github.com/bokmann/stonepath/tree/master/docs interesting from a functional requirements point of view.

Thomas Moerman18:02:56

Implementation-wise, a combination of events+state machines would probably be suitable.

ehernacki19:02:05

Interesting, thanks!