4 ms·

Something that might be missing from these discussions is when event driven architecture is even appropriate. The short answer is if your customer did something

Something that might be missing from these discussions is when event driven architecture is even appropriate. The short answer is if your customer did something and expects a response it's not even driven, that's just request/response. Event driven is when something happens out of band. E.g. you push your code to GH, which triggered a build. In this example, you reloading the page to see that your updated code is request/response, however that CI build that was enqueued is event driven. Hope that helps.

berkes 3y ago
It's not that Simple. Request-response isn't a factor to choose ES or ED architectures on. You can have request-response, inline, blocking, cycles with ES or ED. And you can have async without ES or ED just fine too (e.g. workers, queues, actors, multithreaded etc)
- asimpletune 3y ago
  > It's not that Simple. It can be as complicated as you want to make it. My original point was to supply the missing context that explains 95% of use cases. > Request-response isn't a factor to choose ES or ED architectures on. One's business use case and how it translates into an appropriate messaging pattern is arguably the most important factor to base an architecture on. > You can have request-response, inline, blocking, cycles with ES or ED [...] Yes, of course. And it's fair to say, at any point in your life, that one can do anything that one wants. Like, one could have rollerblades for hands, or one could implement request/response functionality with an event driven system. But once we've moved past that, probably the next order of business is to justify the extremely good reason for overriding all prevailing common sense.
  - berkes 3y ago
    No need to be condescending. ES and ED architectures have good use-cases. And CRUD has good use-cases, and RDMSes and time series and document databases. Non will ever fit perfectly and non are a silver bullet. Choosing the right architecture is an an art. Experience helps. And being able to look into the future even more. Point being: a silly parameter as "wether you need the response to a request to have the data" is certainly not the only metric to base architectural choices on. It's not even a significant metric. It's at most a technical requirements. And one that can be fulfilled with many architectures. Like event sourced architectures even.

berkes 3y ago

It's not that Simple. Request-response isn't a factor to choose ES or ED architectures on. You can have request-response, inline, blocking, cycles with ES or ED. And you can have async without ES or ED just fine too (e.g. workers, queues, actors, multithreaded etc)

asimpletune 3y ago
> It's not that Simple. It can be as complicated as you want to make it. My original point was to supply the missing context that explains 95% of use cases. > Request-response isn't a factor to choose ES or ED architectures on. One's business use case and how it translates into an appropriate messaging pattern is arguably the most important factor to base an architecture on. > You can have request-response, inline, blocking, cycles with ES or ED [...] Yes, of course. And it's fair to say, at any point in your life, that one can do anything that one wants. Like, one could have rollerblades for hands, or one could implement request/response functionality with an event driven system. But once we've moved past that, probably the next order of business is to justify the extremely good reason for overriding all prevailing common sense.
- berkes 3y ago
  No need to be condescending. ES and ED architectures have good use-cases. And CRUD has good use-cases, and RDMSes and time series and document databases. Non will ever fit perfectly and non are a silver bullet. Choosing the right architecture is an an art. Experience helps. And being able to look into the future even more. Point being: a silly parameter as "wether you need the response to a request to have the data" is certainly not the only metric to base architectural choices on. It's not even a significant metric. It's at most a technical requirements. And one that can be fulfilled with many architectures. Like event sourced architectures even.