Most architecture mistakes come from the same place: designing for a future that does not exist.
Microservices, Kafka, event-driven systems, real-time pipelines. All of this can make sense. But most products fail because they do not deliver value, not because they cannot scale.
This is not new.
Basecamp scaled for years on a monolith and argued against premature microservices:
https://m.signalvnoise.com/the-majestic-monolith/
Shopify handled massive growth with a monolithic Rails app before extracting only what was needed:
https://shopify.engineering/shopify-monolith
GitHub did the same, focusing on developer productivity over architecture fashion:
https://github.blog/engineering/architecture/why-github-still-uses-rails/
The pattern is simple: start simple, evolve when reality forces you to.
At CrossKnowledge, one decision that really worked was extracting the frontend from the backend. Nothing fancy, just less coupling, faster deployments, and easier maintenance. Netflix and Spotify did similar things by decoupling UI from backend systems early:
https://netflixtechblog.com/tagged/ui
https://engineering.atspotify.com/
On the other hand, we also tried rebuilding a large part of our core product with Kafka and microservices. It looked modern. It was complex, hard to operate, and brought no visible value for users. So we stopped. Google teams openly talk about killing systems when complexity outweighs value:
https://research.google/pubs/pub45406/
Today my default position is simple: maintainability over trendy architecture. Most teams try to solve all future problems upfront and end up over-engineering. Even Amazon’s architecture evolved incrementally, based on iteration and ownership, not perfect design:
https://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html
The real lesson is that architecture follows teams more than technology. Conway’s Law is real:
https://martinfowler.com/bliki/ConwaysLaw.html
Microservices only work when teams and operational maturity are ready for them, like at Netflix or Uber:
https://netflixtechblog.com/tagged/microservices
https://www.uber.com/en-US/blog/microservice-architecture/
My personal rule is simple:
Maximize short-term value for users, validate assumptions, and iterate.
Good architecture is not about predicting the future.
It is about not slowing down the present.