Please enable JavaScript.

Coggle requires JavaScript to display documents.

Microservices (Design considerations (Transaction (ACID (Meaning (Atomic…

- - - - Bottom Up Approach
        
        The success highly depends on how well you know the system
        
        Moving data from a live system is significantly more difficult
        
        Break down a monolithic DB into smaller DB and work back up by creating microservice for those small DBs
      - Top Down Approach (More recommended)
        
        Start with microservices and have them all connect to the monolithic DB. Then monitor the traffic and leverage that knowledge to model the new DBs
    - - Meaning
        
        Atomic
        
        Operation is completed or failed entirely
        
        Consistent
        
        Guarantee all data model rules and constraints are applied to all data operation
        
        Isolated
        
        Guarantee visibility rules are well defined so that no transaction can read data that is in incorrect state
        
        Durable
        
        Once save, guaranteed to be in the datastore until modified
      - Solutions
        
        Identify areas where ACID transaction is truely needed, and wrap microservice are it
        
        Cannot leverage any model with this type of architecture with any success
      - Problems
        
        Difficult, if not impossible, in distributed architecture)
    - - Strive for eventual consistency (Aim for this)
- - - - Create a unique token called Trace and use the token in all the logging in the call stack by passing the token to the down stream services
- - - - More deployable artifacts
      - Too many different technologies used
    - - More service = more network communications = more latency
      - Causes
        
        Services are too fine grained
- - - - Define rules how services at different classes are communicated
      - Design service into different classes (e.g. Data service, Business Process service, Edge Services)
    - - Difficult to maintain the artificial rules across different teams
      - Can lead to unnecessary services that do nothing but just passing data through (and incur latency) in order to meet the requirements of the rules
    - - Should be used with care and only for a transitional method
  - - - Single DB to handle all services
    - - Getting some agility without separating data into different data stores