Beyond Microservices in a one page


  1. Clients know too much: Auth, Encryption, etc.
  2. Hard to change a microservice -> Don’t know who’s using it. Hard to add a new microservice -> No one may use it. Being political.
  3. Responsibility for the failure in a microservice. What happened when a microservice fails.
  4. REST is slow

Solutions – Useful Architectures

  1. API Gateway
    1. Provides: Auth, Routing, Rate Limiting, and Logging and analytics.
    2. It can be a bottleneck if all internal services access the API gateway. => Anti-Pattern
    3. Service Mesh. Side-car. Shared library.
      1. Work as a proxy(service discovery, routing).
      2. Control re-try pattern. e.g. circuit-breaker. Too much retry causes a problem.
  2. Event-Driven
    1. Broadcast -> Subscribe. Being independent of the other services.
  3. DB for each microservice
    1. local DB can provide local state for each Microservice, which allows independence.
    2. DB can be a small, cloud-based key-value DB.
  4. Schema
    1. Very important to keep the consistent schema (contracts) among services.
    2. Can register all schema in the schema registry, which all microservices will share.
  5. Serverless
    1. Can have state by storing in cloud DB or storage.

Still missing

  1. Durable functions -> Azure functions?
  2. Triggers and data from stores to functions -> Maybe Azure event grid is the answer for this.
  3. Unified view of the current state -> Hard to check what’s happening long the workflow of the entire system.




Leave a comment

Your email address will not be published.