Micro-services Resiliency Patterns

Rate limiter Design pattern

A rate limiter can hold back traffic peaks

Retry Design Pattern

Transient faults could occur which include the loss of network connectivity for a moment to services, temporary unavailability of a service, or timeouts that during busy time. These faults are often self-healing, and if the action is repeated after a suitable short delay it is likely to succeed.

Chain of Micro Services
  • Distinguish “retryable exceptions” from ““non-retryable one. It’s pointless to retry request, when user doesn’t have permissions or payload is not valid. Also, setting max retry count is a good practice.
  • Adopt error budgeting — technique, when you stop making retries if rate of retryable errors exceeds threshold, e.g. if 20% of interactions with service D results in error, stop retrying it and try to degrade gracefully. Amount of errors might be tracked with rolling window over N last seconds.

Bulkhead Design Pattern

Circuit Breaker Design Pattern

Timeout Design Pattern

  • Dynamic environments and distributed systems — like microservices — lead to a higher chance of failures.
  • Services should fail separately and should not bring down the application as a whole.
  • Most the outages are caused by changes, reverting build is not a bad thing.
  • Fail fast and independently. Teams have no control over their service dependencies.
  • Architectural patterns and techniques like caching, bulkheads, circuit breakers and rate-limiters help to build reliable micro services.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kuldeep Gulati

Kuldeep Gulati

Hands-on Architect and a speaker with experities in building Resilient Micro Services.