> I've been burned by both but I think I still lean away from event based systems.

I think this is the right call overall but I don't want you to completely shy away from events as a tool. You can still use event modeling to decouple systems you otherwise would need to couple in an ugly way.

For instance, they're extremely powerful when it comes to retrofitting wanted side effects into legacy systems you're unable or unwilling to redesign around a new business need.

I've used event systems to add massive business value to an order system where the order and its legacy systems remain in a transactional RDBMS but events are used to augment the order with information from various other systems we previously never had any insight or way to link it all back to our RDBMS. (there was just too much data and it was ever growing in scope.)

I make a lot of design decisions not based on what I can understand but on what I’m willing to teach/support.

And I’ve never even witnessed someone teaching event thinking to people, let alone mastered that skill myself. People either self teach event based thinking or struggle. In a teamwork situation that property is a huge con. I have no interest in creating an underclass of developers so I can look good because I’m the only one who can fix certain problems.

Similar feelings for the first point, we differ on the second.

Personally speaking, I never saw any kind of underclass developing with these evented systems techniques, if anything, blockage decreased and teams got decoupled. (caveat that could have just been introduction of solid versioning and maintaining backwards compatibility)

I saw much greater attrition with the onset of unit testing and enforced code reviews. But that also led to much higher quality developers so maybe that had a bit to do with it. (the ones that stayed got better and the ones that joined were stronger)

> People either self teach event based thinking or struggle.

I feel like if you're dumping a new way of thinking on your staff, any staff, and then expect them to self teach or have zero support you're asking for problems, I don't think that makes event systems more complicated than REST. Rest involves a crap tonne of thinking to get right if you're able to easily blur the lines between RPC and REST or the client and server code.

Isn't sequentiality just an implementation detail too?

We use Apache Camel to orchestrate messages and you just declaratively state where you want sequential vs multicast / parallel behavior.

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.

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.

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.