3 ms·

With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. It's priceless

With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. It's priceless to see their expressions when senior mgmt. and business owners finally find out.

gullyfur 7y ago
Could you elaborate what you mean by transactions?
- AlexCoventry 7y ago
  Sequences of interactions with the DB which are either atomically committed to on success of the sequence, or rolled back on failure, so that the DB is in the same state it had before the interactions began.
elbear 7y ago
Can you explain why you lose that ability? It's not obvious to me.
- NateEag 7y ago
  One of the fundamental laws of microservices is that each service is responsible for storing its own state. Nothing else is allowed access to its backing store. Given that, once you have more than one service in your architecture, you cannot coordinate transactions across the distinct storage mechanisms - they are distinct databases and are therefore subject to the CAP theorem and other complexities of distributed computing. Of course, nothing's stopping you from putting all your features into one service to avoid this thorny problem. It's a wise approach for most of us. When you do that you have a monolithic architecture, not a microservice one.
rumanator 7y ago
> With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. I don't follow your reasoning. I mean, the ACID vs BASE problem you described is extensively covered in pretty much any microservices 101 course or even MOOC, along other basic microservices tradeoffs such as the distributed tax and ways to mitigate or eliminate these issues like going with bounded contexts. Why do you believe this is a mystery that no one is aware of?
- JamesBarney 7y ago
  I've seen a couple of projects where the original team didn't think they needed transactions, or underestimated how much harder eventually consistent distributed systems are to reason about than an acid system.
Aeolun 7y ago
It doesn’t matter if you have transactions or not. Just make sure you execute things in the right order! Same for referential integrity, if you just make sure nothing ever goes wrong, there’s no need for it! /s

gullyfur 7y ago

Could you elaborate what you mean by transactions?

AlexCoventry 7y ago
Sequences of interactions with the DB which are either atomically committed to on success of the sequence, or rolled back on failure, so that the DB is in the same state it had before the interactions began.

elbear 7y ago

Can you explain why you lose that ability? It's not obvious to me.

NateEag 7y ago
One of the fundamental laws of microservices is that each service is responsible for storing its own state. Nothing else is allowed access to its backing store. Given that, once you have more than one service in your architecture, you cannot coordinate transactions across the distinct storage mechanisms - they are distinct databases and are therefore subject to the CAP theorem and other complexities of distributed computing. Of course, nothing's stopping you from putting all your features into one service to avoid this thorny problem. It's a wise approach for most of us. When you do that you have a monolithic architecture, not a microservice one.

rumanator 7y ago

> With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. I don't follow your reasoning. I mean, the ACID vs BASE problem you described is extensively covered in pretty much any microservices 101 course or even MOOC, along other basic microservices tradeoffs such as the distributed tax and ways to mitigate or eliminate these issues like going with bounded contexts. Why do you believe this is a mystery that no one is aware of?

JamesBarney 7y ago
I've seen a couple of projects where the original team didn't think they needed transactions, or underestimated how much harder eventually consistent distributed systems are to reason about than an acid system.

Aeolun 7y ago

It doesn’t matter if you have transactions or not. Just make sure you execute things in the right order! Same for referential integrity, if you just make sure nothing ever goes wrong, there’s no need for it! /s