3 ms·
The problem with microservices is that your state is spread over multiple systems. Then again, sometimes it's advantageous to identify parts of your system whe
by kafkaesq 10y ago
The problem with microservices is that your state is spread over multiple systems.
Then again, sometimes it's advantageous to identify parts of your system where aspects of state can be safely decoupled. And in which having them reside in disparate systems (and yes, sometimes be inconsistent or differently available) might actually be a better overall fit.
You completely lose the concept of transactional integrity, so you will have to work around that from the start.
Then again, sometimes your state changes not only don't need to be transactional; it can be disadvantageous to think of them that way.
Depends, depends, depends.
- amelius 10y ago> Then again, sometimes your state changes not only don't need to be transactional; it can be disadvantageous to think of them that way. I'm curious; in what kinds of situation would this apply? > Depends, depends, depends. Flexibility is usually an important requirement. Often you cannot freeze your architecture and be done with it. I think a transactional approach could better fit with this.
- kafkaesq 10y agoI'm curious; in what kinds of situation would this apply? Any situation where the business value of having your state be 100% consistent does not outweigh the performance or implementation cost of making it so.