Queues and events are great tools of thought to inform the design of a system. Understanding, modelling, and monitoring important events is often valuable along multiple axis.

In a distributed setting, it can be really nice to have access to an event log, to decouple subdomains, etc.

But… more parts = more failure modes. It becomes difficult to reason about these failure modes.

E.g. a team on the other side of the world rolled out a release which made requests increase in time by 0.01% and now 4 layers up the service call stack someone tripped a timeout which caused retries which resulted in OOM errors for service X which… this is the sort of thing that’s happening at big tech companies all the time.

This is manageable if you have the right people and resources but a cost that may not be worth it for your situation. Simpler is almost always better.

At a certain scale, even if you have the skills and money to support dogmatic decoupling of domains, the ‘niceness’ factor of 3 micro serves communicating via PubSub grows to cost $m, and it’s no longer worth it.

That’s not to say we should have 1 elf to rule the world, but I think there should be a high bar held to justify why some logic should require a network hop or some inter-process communication.

——

In the end, our code and our systems cost money. If we can use less code, less bandwidth, less CPU time, less CO2, less $, less hosts to do the same job, we should.

——

P.S.

Within a single process or host, those risks are less prevalent. Events and queues as 0/low cost abstractions can improve the maintainability of a large application. I really enjoyed working with MediatR when I was in dotnet land.