Architectural Principles

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.

Microchanges Priciples

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

Articles Related

• 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.