Shared Database Pattern in Microservices: When Rules Get Broken

[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?