Saturday, April 3, 2021

2.5 Partitioning Strategies Event Driven Microservices

April 3, 2021

Here is the link. 

6:09/ 14:07

How to enforce credit limit? 

Order services - placeOrder()

Customer service - updateCreditLimit()

Order management - Order total 

Customer management - Customer - creditLimit 

Partitioning requires you understand the design

Existing monolith:

  • You understand the dependencies
  • But decomposing is a challenge
Greenfield development:
  • No code => no tangled dependencies
  • But no design either!
  • Therefore, do some upfront design/prototyping to understand what you are partitioning
  • Too few
    • Drawbacks of the monolithic architecture
  • Too many - a.k.a.. Nano-service anti-pattern
    • Runtime overhead
    • Potential risk of excessive network hops
    • Potentially difficult to understand system 

communication pattern - sequential or parallel 

Anti-pattern: Distributed monolith
  • Remember the goal
    • Partition your application so that most changes only impact a single service
  • But if you get it wrong
    • Each change requires you to update and deploy all services
  • Therefore: Common closure principle
    • Components that change for the same reason should be packaged together


No comments:

Post a Comment