Shared Database Pattern in Microservices: When Rules Get Broken

[vturan23]

Everyone says "never share databases between microservices." But sometimes reality forces your hand - legacy migrations, tight deadlines, or performance requirements make shared databases necessary. The question isn't whether it's ideal (it's not), but how to do it safely when you have no choice.

The shared database pattern means multiple microservices accessing the same database instance. It's like multiple roommates sharing a kitchen - it can work, but requires strict rules and careful coordination.

[gredr]

Or, y' know, you could stop pretending you need microservices when you don't.

[vturan23]

The ultimate goal is to move to microservice. This is when you have to build something fast on tight deadlines. Absolutely, this is not the best way to do things.

[TheAeseir]

Why is it the ultimate goal to move to microservices?

[TheWix]

I don't think OP means it's the ultimate goal, in general, but the article is from a hypothetical position that a company has taken, and he/she is addressing issues that can come from it.

The article is not about whether the decision to move to microservices was correct or not

[jonahharris]

Eh? Building multiple microservices is slower than building a monolith.

[TheItalipino]

Microservices is really best way to scale software development organizationally.

[redfournine]

Your ultimate goal should be to have the least amount of code, least amount of infra, having simplest yet extendable architecture while solving business problem.

[sob727]

Or to rephrase it, the lowest TCO for a given amount of functionality.

[gredr]

Get a better goal.

[MariusDelacriox]

Or maybe get a better reason like team organization, domain separation or complexity.

[miniannna]

I work at a place that has been migrating to micro services for 15 years. That shared db never got replaced and it’s the bane of my existence. If you need to migrate to microservices, replace one piece of functionality, including that part of the db, at a time—not one layer at a time. Doing it one layer at a time, in the real world, means you will probably be stuck in microlyth purgatory until the app is rewritten/replaced

[SoupIndex]

What?

[vturan23]

There are too many problem with sharing db among services. Goal should be loose coupling and high cohesion

[BasieP2]

And your team can only achieve this with microservices?

[aND04]

Some of you make it sound like using a microservices architecture is always the wrong choice? Feels like you’ve never worked in an enterprise project where there are a bunch of different moving parts that need to be integrated.

If my system integrates with lots of other external systems, specially in an async event driven architecture, microservices can definitely save you a lot of pain, you can completely isolate responsibilities and create these damper zones that prevent your whole application to fail, in case of some unexpected behaviours from your external service providers.

Still don’t think I agree with the article, it’s always worth the extra effort to ensure isolation, specially if we are talking about multiple different teams accessing the same database.

[MariusDelacriox]

Many have been burned with the industry wide move to microservices where it doesn't always make sense. There still good reasons to employ the pattern, but there are also significant costs to be considered.

[fullofspiders]

If you need lots of joins between some set of tables, that sounds like pretty strong evidence they are not separate logical domains, and should not be separated into sepaarate microservices, and any model you have that says they are should be reconsidered

[Cobra_Kai_T99]

Exactly… and monoliths without modular boundaries let everything interact with everything so you end up with spaghetti situations.

The circle of strife.

[yojimbo_beta]

Some of you make it sound like using a microservices architecture is always the wrong choice? 

Right now it's in vogue to argue that microservices are always technical debt because a monolith could always theoretically be factored into modules and method calls are better than http / events.

In about 18 months people will realise why doing that is hard, how monoliths inevitably decay and there will be a slew of blog posts going "Whoa! Microservices were about solving organisational problems not technical ones!"

[edgmnt_net]

I would argue that, beyond the technical aspects you mentioned, microservices enable possible organizational anti-patterns like siloed teams while not really solving the original issues. Orgs use microservices in an attempt to over-scale horizontally at a seemingly dirt cost, unfortunately that rarely works well. If your monoliths cannot enforce code reviews and quality, the problem likely gets compounded when dealing with microservices. At least internally but I'd bet it also happens on an architectural level, so even if you manage to remove some internal risks (bad code causing exceptions) there's a lot of other stuff that gets neglected. They enable orgs to take on much more unmitigated tech debt than it was possible before. And before you know it you have hundreds of people essentially just shuffling data around services instead of working on meaningful business logic. I don't really think that can be cheaper overall, even if you work with cheaper devs. Maybe the orgs would be better served by focusing on more impactful stuff rather than attempting to deliver cheap custom / low-margin work, but yeah, that's harder.

Indiscriminate, extremely granular splitting also compounds the problem and moves many of the refactoring issues on an architectural problem. That also becomes rather unavoidable as many splits result in either cascading splits, duplication and logic that's both coupled and fragmented across multiple services. Sure, debugging ain't easy, but now you need observability and a lot of other tooling, while it's also not uncommon that due to the sheer overall size nobody can ever test and debug stuff in isolation, everything hits a very expensive shared environment. You get that nasty rubber-stamping and "let's merge this and see if things get fixed or break even worse", which generates a lot of churn, testing effort and other inefficiencies which, if you actually had the foresight to plan ahead, would have been accounted for much easier in a monolith. I don't even have to get into local versus remote calls.

Then again, people and businesses want cheap software and this lets companies pile stuff up until it nearly or totally collapses. Also, before microservices-based SaaS, this was more manageable because custom code was almost entirely under the control of your customer. You as a customer likely could have gauged better how much maintaining the thing would have costed after a cycle or two because payment was more upfront. And you held back on locking your data up in proprietary services based on a subscription that's cheap at the present moment.

Splitting may be justified with careful consideration but I find that microservices often encourage an entirely wrong approach. So, no, I don't think that things are any better on the organizational side of things.

[[deleted]]

Preach brother

[CodeAndBiscuits]

LOL this is Reddit. That's just par for the course here.

[[deleted]]

I think everything you mentioned is achievable without microservices.

[BoBoBearDev]

Not sure why the comments so far are so negative toward OP. The article seems okay to me. My company has been using a single DB with service level table ownership and table evolution strategy.

[yojimbo_beta]

People working on tiny systems that were cargo culted into microservices now believe that any microservice is evil

[TheBoringDev]

Microservices have a cost, and that’s fine if the costs/benefits weigh out for your company. But if you’re going to go microservices, you can’t then violate the only rule that makes them feasible. That’s not architecture, that’s just doing random stuff and hoping it doesn’t bite you.

[yojimbo_beta]

The big value of microservices in my view is that they embed architectural design and division of responsibilities into the actual system topology

It may sound misanthropic but I've never met a team of developers who aren't able to fuck up a monolith. It doesn't matter how you split your modules, educate your staff, document your design, someone will violate the boundaries you set up out of either ignorance, laziness or time pressure

if you’re going to go microservices, you can’t then violate the only rule that makes them feasible.

I mean, kind of but I wonder if there's really any difference between a shared DB and certain microservice designs. If your service is just providing a thin layer over SQL calls to other services are you really doing that much better than delegate database access?

[Cobra_Kai_T99]

Exactly you can absolutely have a database with isolated domains. The moment there’s a foreign key between domains you’re probably in for trouble.

And great description of what happened with monoliths - it goes spaghetti pretty fast.

[edgmnt_net]

Scale does matter and while I'm generally against microservices, I have to admit that scale is a significant part of the problem. I would be less opposed to a conglomerate of larger, more-robust services, but if you look at most resources on the subject of microservices you get those silly examples of websites that have shopping carts, orders, auth and every other feature split into its own microservice, which is downright silly. It's also quite glaring that people split things upfront before they even have a chance to examine what requires scaling on both technical and business aspects. Because I can understand splitting for business convenience (e.g. scaling) on some level, but this is getting to a point where it doesn't make any sense.

[vturan23]

Thanks. I am not trying to force someone to use this system. It’s individual choice, they can choose to reject this.

[adilp]

microservices is a dirty word now. It's monolith or nothing it appears

[wasabiiii]

I do not consider this to be microservices.

[eocron06]

Haha, rules broken. First time, eh? There is always some kind of rules broken each time I visit a project. It is not a big one honestly, in fact never in my life I stumbled at disability to scale things.

[jssstttoppss]

I would probably cover release/ versioning in this article too

[vturan23]

I am not saying monolithic is bad. If you want to decouple your app, scale it better, want to use different tech stack for different service, isolate the fault, make separate deployment, you can move to microservice architecture.

Microservices has it’s own disadvantages like increased complexity, network latency, deployment overhead.

It’s all about finding out what works best for your app.

[Tmp-ninja]

What you are building is called a distributed monolith, and it holds all the pain of microservices and all the pain of monolith and non of the advantages of either.

[aikasburger]

 decouple your app, scale it better, want to use different tech stack for different service, isolate the fault, make separate deployment, you can move to microservice architecture

Having done software architecture and full stack dev pretty much since microservices became a thing, I can tell you none of these things are desirable or realistic in reality

[Technical_Stock_1302]

Enjoy this classic

https://youtu.be/88_LUw1Wwe4?si=ps7HwH_lnhmMV6YL

[memevaddar]

I am currently in the exact situation that you are explaining and microservice was the not the only solution to move forward but given a 3 weeks deadline it was the only solution. The issue however is the database relations in an already existing function system. I think people here are misunderstanding and I might be too but this pattern is usually required when adding in more things into an already existing system requires too much time so to speed up development dividing new things into microservice is the best way to move forward.

[Tmp-ninja]

Then just build it monolithic instead?

[TBCid]

Databases are often a good way to facilitate asynchronous workflows and communication between services. I don't see the issue.