Service Autonomy Principles
- One service should not depend and/or rely on any other service to do its work.
- Any service failing should not affect other services.
- Any external service should be considered unstable and be expected to fail
- If any external service fails then there should not be a cascade of these failures into our service, we should instead degrade the functionality so that such failure doesn’t become catastrophic to our service.
- Each service update should be dependent without requiring any other service to coordinate updates as well. In other words, the update of any service should affect the rest of services.
- Services should have the ability to be changes and deployed any time
No Coordinated Transactions Principles
- One service should not be forced to enroll in a transaction which is owned by another service.
- The service should not rely on other services
- The service should not be allowed to do complex transactions, be involved with multiple services changing continuously of states, and/or interacting with multiple services and/or objects.
- ACID 2.0 model.
- Commutative. Idempotent. Distributed.
- Achieving high throughput by altering our data model.
- Create as small of database transactions as is logical.
- Change as little as possible.
- As events, capture user-intent rather than data objects
Change Tolerant Principles
- Defensive coding.
- How tolerant is your service in respect to other services changing?
- How the service will react to failures?
- How the service will react with changes in another service’s API?
- How the service will react with changes in events and/or messages it receive?
- ACID 2.0 Article:
Jimmi Bogard. “ACID 2.0 in action.” Los Techies. . (2013): . . https://lostechies.com/jimmybogard/2013/06/06/acid-2-0-in-action/
© 2016, Alejandro G. Carlstein Ramos Mejia. All rights reserved.