Shared databases are not modular, they are just a weakness

1 pointsby davidvartanianil y a 4 mois1 comments

I used to believe that defining clean interfaces and contracts between services was enough to maintain modularity. I shared a database because it seemed like the path of least resistance. I was wrong. Sharing a database or any resource that crosses the boundary to a foreign component creates a "welded" joint that defies any interface definition. It creates a failure cascade waiting to happen.

Many engineers want to avoid the friction that comes with strictly defined data ownership. They seek a polite, neutral zone to avoid confrontation. I believe this approach is intellectually dishonest. By avoiding the confrontation required to enforce true modularity, you build systems that are destined to fail the moment a schema changes.

I had to learn this the hard way. I now enforce strict separation at the data layer for every component. It is harder upfront, but it's the only way to build systems that scale without collapsing under their own weight. If you are sharing databases or making your domain data cross the boundaries to foreign modules in any way, you are not building a modular system. You are just postponing the inevitable breakdown.

1 comments

dborehamil y a 4 mois

True words. However the effort to impose modular data ownership is not to be underestimated. A monolith with a single database might cost 100X less to write and maintain than the equivalent services oriented system with isolated data stores.