What does architecture mean to you? The set of components and how they’ll interact is what it seems to mean in my world.

I'm not sure I have a clear definition.

What I do know is that I avoid confusing tools, frameworks, languages, libraries, or really anything you could call "software" with architecture. They're all just tools that enable me to draw boundaries around contexts.

To attempt to define it, I would say architecture has far more to do with _where_ I draw bounded context lines than how or what tools I use to do so.

I saved this talk[1] in my favorites because he manages to distill ways to induce the right boundaries out of business needs. (surprisingly not an uncle bob talk!)

For a more concrete example I separate a CQRS/ES architecture philosophy from the implementation detail of a message bus in this comment I wrote further down in the thread [2].

[1] https://www.youtube.com/watch?v=ez9GWESKG4I

[2] https://news.ycombinator.com/item?id=19905016

> To attempt to define it, I would say architecture has far more to do with _where_ I draw bounded context lines than how or what tools I use to do so.

Your definition makes no sense at all. There is no distinction. Architecture specifies which components comprise the system, their interfaces, their responsibilities, and how components are expected to interact with each other. You pick certain tools because they are expected to handle certain responsibilities, because they implement certain interfaces, and because they support or enable certain types of interactions. There is no distinction.

Well I did say I'm not sure I had a clear definition..

Distinction wise, didn't you just lay out the same distinction?

And please don't get me wrong, you can have a pub/sub, rest, or event driven architecture. I would just posit that you're basing your architecture on fundamentally the wrong thing. Those sorts of things are design choices, maybe big choices but choices that are much better off being driven by the needs of the problem at hand which in any complex system is many and diverse. Your systems framework should be flexible enough to cater to whatever makes sense with the problem set.

Pushing every single problem into the same rest api, rpc, or pub/sub event system is going to end the same way.

The next time you see someone talking about some kind of architecture driven by some kind of tool replace the tool's name with "Database" and see just how stupid it sounds to even be discussing it.

> Using a database will allow for the same communications, but it’s a little more simple. Single query/result, connection pool, and transactional models are supported out of the box. Service discovery is a matter of just querying the right tables. There is an operational cost of maintaining the database, and possibly having a piece of infrastructure that impacts all services. But, all the production grade databases support clustering, but still things can go wrong and it can lock the whole system up (looking at you MyISAM).

> The primary benefit of a database driven architecture is that data is freely available. Services just provide data and don’t mandate how it is used. You still have the necessary coordination in developing a system; part a generates rows like this and part b will modify it like that. But now you can have any new service start non-destructively consuming those tables. This free flow of data allows for rapid prototyping, simple services crosscutting, intuitive monitoring and easier development.

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

REST is more likely to result in a partially ordered sequence of actions from one actor. User does action A which causes thing B and C to happen. In event driven systems, C may happen before B, or when the user does multiple things, B2 is now more likely to happen before C1.

IME, fanout problems are much easier to diagnose in sequential (eg, REST-based) systems. If only because event systems historically didn't come with cause-effect auditing facilities or back pressure baked in.

> 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.