3 ms·

Isn't sequentiality just an implementation detail too? We use Apache Camel to orchestrate messages and you just declaratively state where you want sequential v

• hinkley 7y ago
  I don’t mean sequentiality of events I mean sequential steps in the process. All of the side effects of my button press happening in order. If you’re trying to say that’s an implementation detail instead of design elements then I’ll counter that by that yard stick, the difference between email and Slack are just implementation details.
  • zmmmmm 7y ago
    I mean that is orthogonal to whether you are using messaging or not. With API calls you default to doing them in order but you can certainly multithread the calls and lose the deterministic order if you want. With messaging you default to sending them off in parallel and not knowing which are received / processed / completed before the others, but the non-default is available there too. You have a message router that knows what has to be ordered and what doesn't and manages the flow. In both cases the non-default requires a bit more work but in both cases it's available and it just depends what your most critical needs are. One thing though is that as systems scale up and get more complex, you want less and less to have blocking API calls anywhere that you don't need them, as those quickly become your bottle necks and hard failure points.
• lugg 7y ago
  Yes but I don't think hinkley was stating otherwise, only that it is generally speaking easier to reason about when things are sequential. Of course, personally I find RPC to be impossible to reason about because you can't really guarantee anything in a distributed system.