When we first split our monolith into microservices, it felt like a victory.
Smaller services. Independent deployments. Clean boundaries. We even ...
For further actions, you may consider blocking this person and/or reporting abuse
Governance is key in a distributed architecture. But for me the most important one before going for it is to have a good knowledge of the domain. Without it, you will likely end up having a distributed monolith even if each microservice has its own database and clear governance.
Good read, thanks for sharing!
Absolutely agree — strong domain understanding is what makes governance effective. Without clear domain boundaries, you’re just distributing complexity and calling it microservices.
This hits because it names the part everyone avoids saying out loud.
Most “microservices scalability” stories quietly assume the database will somehow absorb the blast radius. It won’t. All you’ve really done is turn vertical pressure into horizontal chaos and aim it at a single shared state.
The line about local decisions with global consequences is the real lesson here. A service adding “just one more query” feels harmless in isolation, but at scale it’s indistinguishable from coordinated abuse. The database doesn’t see services or intent — it sees contention.
What I appreciate most is the framing around data ownership. That’s the actual boundary, not deployment units. If two services write to the same tables, they’re coupled whether you admit it or not. The coupling just moved somewhere harder to observe.
Also important callout on caching: it masks symptoms, it doesn’t fix structure. If your write path is still shared, you’ve only delayed the pain.
This is one of those posts that should be required reading before anyone says “let’s break it into microservices.” Not as a warning against them — but as a reminder that scalability starts with data, not pods.
This really resonates because it clearly calls out the part most teams quietly work around instead of addressing head-on. I like how you frame the database as the true pressure point — it’s a strong reminder that architecture choices don’t disappear just because we distribute services. The point about local decisions turning into global consequences is especially sharp, and it mirrors what I’ve seen in real systems under load. Your take on data ownership being the real boundary feels like the right mental model, and it makes the coupling visible instead of hidden behind deployments. Posts like this don’t argue against microservices — they help people approach them with the right expectations and a much healthier starting point.
YESSSS decoupling data is a problem I see so many young companies run into. They just want to move faster and faster and after 2-3 years they start going "wait why is that grid taking 30 seconds to load...."
Exactly — early speed without data boundaries turns into invisible coupling, and the bill always comes due in latency and complexity.
This is painfully accurate, I’ve seen microservices that were really just a monolith arguing with itself over one database.
Haha, that’s such a sharp observation — you captured a real-world anti-pattern perfectly. Anyone who’s been in the trenches with microservices will feel this one immediately 👏
While there is a redemption arc in the post, the developer that thinks it is a good idea to use a single database doesn't understand modularity or has just enough knowledge to be dangerous.
When the application is monolith it is possible to keep domains separate in a single database.
It is also possible to create cross domain calls.
And when one or more domains become a bottleneck, then it is time to start to move them out of the monolith.
This flow is the easiest part of scaling.
I really appreciate your breakdown—it makes the scaling journey much clearer! I agree that starting with a single database can work if domains are well-separated, and it’s smart to wait until a bottleneck appears before splitting things out. In my experience, modularity is more about how you structure code and interactions than the number of databases, so your point resonates. I’m curious how you handle cross-domain calls in practice without introducing too much coupling. Overall, this approach feels practical, and I’m excited to try it in a project and see how it scales.
Create a public domain API and only use that API. The thing you do to let microservices communicate, you can do in a monolith.
By treating your application like it already is split into microservices, you will understand the domain communications before the time comes you need to scale.
Great point — that mindset shows real architectural maturity. Designing clear domain APIs early builds understanding and discipline, so scaling later becomes an evolution, not a rewrite.