This was originally a question for Stackoverflow, but it’s actually a rant.
Why bother with EDA at all? Because all I see is job offers for people specialized in “event-driven design”. In my opinion, especially when using a high performance, low resource language like Go, EDA is overkill. But anyhow, since I’d like to get that money (LGTM), I need to know about this new old born-again hype train, event-driven architecture.
I often see examples that mention an event where the potential customer clicks on a product and that leads to an event getting sent. I wonder what the point is.
So you have the whole server side distributed microservices thing that communicated with one another, sends, I’m sorry, publishes events, and then there are consumers or subscribers of events. And it’s all realized with nats or kafka. I’ll leave the AWS/GCE craze for later, everyone needs to be a freaking specialist in using a costly, foreign, insecure cloud to even be considered to get hired.
Anyhow. You have this display side of things. The “customer clicked on a product” example that is so wrong on so many levels. This event is trivial, you have the ID of the clicked product, display a product detail page, no big deal. But in a EDA it becomes something special. Now you have to send that back to the server side of things where it gets processed and your client applicated instead of doing a very simple navigation to the product detail page, now it has to listen for an event when “customer clicked product processed successfully” and only then it can navigate to the actual product page.
Is the the reality of an EDA display side app? How does communication between the single page app (aka the display side) and the broker even work when there are no websocket outlets for kafka or nats (or rabbitMQ activeMQ .. whateverMQ or other)? And how would this work with a traditional, server side rendered website? It’s counter-benefitial for SEO, when all the links you click are no actual links but javascript functions.
I believe this EDA hype is a load of bull. Especially with such examples as “customer clicked on a product” event. I believe it’s a way for the server side only, where microservices communicate with each other. The amount of resources wasted is absurd. Every single entity service needs a separate database. So instead of having 1 replicated, distributed database where all service, in this case, frontends access and sync to, you have now 10s or 100s or 1000s of independent, separate database installations with 1 table/collection. And all are kept in sync via those event messages.
So instead of having simple, short, RESTful messages you have this abomination where 100s of microservices are kept in sync via those messages. 1 write is propagated to 100s of databases with 1 table/collection. Or else you’d be out of sync. And of course if one of those databases is offline during that event, later when it’s back online it catches up via some replay log that kafka/nats/other has.
And what when you have a new service, does is go through all the events it’s supposed to listen to since the beginning?
Or is there a “sync state” message? What if the state is inconsistent between nodes?
And now, what about the display side of things.
In a SPA context I could see having an event-muxer. An event transceiver. That handles actual events from the client, mouseclicks, mouse movements, keyboard actions and translates them to events that are sent to the backend, where they’re processed and other events sent that are picked up by this event hub and again action are being taken like navigating to a product-detail page or a cart page being shown etc.
Companies aren’t aware that with Go you can have 5000 concurrent requests and without an error on commodity hardware, which costs 150€ / month at most, where you have 1 GE traffic flats. But on AWS(or GCE) you have 1 TB of traffic per instance and then 10TB costs around 900€, which is ludicrous. I could have 10GE 20TB traffic for 120€/month on a single server. So I could rent almost 8 full blown servers for the price of 900€ and have double the amount of traffic and 10x the amount of bandwidth. Oh and I also have 2x1TB NVM drives on each of those servers and full 8core CPUs and 64GB of RAM on each. vs what amazon has there. Every economist must be aware that when someone manages hardware for you the price increases.
If you expect such huge numbers of visitors, why are you building on top of a foreign cloud? that has you by the balls as soon as you actually meet the criteria you’ve spent so much effort into building this huge microservice abomination?
Additionally to a simple RESTful service that you would normally use, you now have to write websocket kafka stream converters. All communication is now via websocket. HTTP is fault tolerant. Websocket isn’t. You need a websocket library both client and server side that checks if the connection is healthy. What if you switch networks like it’s common on mobile phones and 3/4 if not more visitors nowadays are using mobile phones.
To each their own. I believe EDA in a Go context is overkill, except if you really expect over 15k concurrent users. Then it starts getting interesting but then also other problems arise.