I think the "When Not to Use Event-Driven Architecture" is wrong.
It is only right if you make the architectural assumptions of using multiple microservices.
If you use a simpler, in-memory variants none of the downsides apply.
I would add that you can use event driven architecture in a monolith.
And you are not required/forced to use a bus or message broker and especially not as a separate microservice.
In a monolith you can just call the code/event handlers directly in a giant switch/if statement/function.
You can even replace the message brocker with a database like postgres.
There is a whole article on how to use postgres as a job queue and it can be used the same to distribute messages as well
And you can simplify even further by using sqlite -> so everything is just a single service. Sqlite is even more stable/tested/used than any other database out where.
That's why its so hard to write articles about technological/architectural decisions, because every little detail is important and can completely turn around and/or negate any pro-con comparison.
Thanks for your insightful comment! You've highlighted an important aspect of Event-Driven Architecture (EDA)—its flexibility and adaptability across different architectural styles, not just in microservices. Indeed, incorporating EDA within a monolithic application can leverage in-memory or database-based event handling, sidestepping the need for a dedicated message broker. Your mention of using databases like PostgreSQL or SQLite as alternatives for message distribution illustrates the versatility of EDA in accommodating various implementation strategies. This underscores the necessity of considering specific project requirements and contexts when discussing the pros and cons of architectural choices. I appreciate the reminder that technology discussions should account for the nuances that can significantly influence decision-making.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the "When Not to Use Event-Driven Architecture" is wrong.
It is only right if you make the architectural assumptions of using multiple microservices.
If you use a simpler, in-memory variants none of the downsides apply.
I would add that you can use event driven architecture in a monolith.
And you are not required/forced to use a bus or message broker and especially not as a separate microservice.
In a monolith you can just call the code/event handlers directly in a giant switch/if statement/function.
You can even replace the message brocker with a database like postgres.
There is a whole article on how to use postgres as a job queue and it can be used the same to distribute messages as well
And you can simplify even further by using sqlite -> so everything is just a single service. Sqlite is even more stable/tested/used than any other database out where.
That's why its so hard to write articles about technological/architectural decisions, because every little detail is important and can completely turn around and/or negate any pro-con comparison.
Thanks for your insightful comment! You've highlighted an important aspect of Event-Driven Architecture (EDA)—its flexibility and adaptability across different architectural styles, not just in microservices. Indeed, incorporating EDA within a monolithic application can leverage in-memory or database-based event handling, sidestepping the need for a dedicated message broker. Your mention of using databases like PostgreSQL or SQLite as alternatives for message distribution illustrates the versatility of EDA in accommodating various implementation strategies. This underscores the necessity of considering specific project requirements and contexts when discussing the pros and cons of architectural choices. I appreciate the reminder that technology discussions should account for the nuances that can significantly influence decision-making.