resilient microservices design pattern

Question

in reactive programming Resilience is achieved by replication, containment, isolation and delegation.

two of the famous design patterns are Bulkheads with supervisor and circuit breaks. are these only for reaching isolation and containment?

what are the most famous design patterns for microservices and specially the ones give resiliency?

Answer 1

Reactive Programing can not be just resumed in design patterns. There are many considerations about systems architecture, dev ops and so to have in mind when you are designing high performance and availability systems.

Specifically, about resiliency, you should be thinking, for example, in:

• Containerization
• Services Orchestration
• Fault Tolerant Jobs
• Pub/Sub Model
• And looots of other things :)

Answer 2

Other than BulkHead and CBs, few other things that can be implemented:

• Retry Pattern on Idempotent Ops. This requires the Operation to be retried is Idempotent and will produce the same results on repeated execution.
• Proper Timeout Configurations like Connection, Command Timeouts in case of network dependency
• Bounded Request Queues at Virtual Host/Listener level
• Failover Strategy like Caching

Redundancy, Failover Systems can be incorporated to achieve resiliency against system failures as well

Answer 3

You can implement various resilience patterns to achieve different levels of resilience based on your needs.

• Unit Isolation –split systems into parts and isolate the parts against each other. The entire system must never fail.
• Shed Load – Implement a rate limiter, which sheds any extra load an application can’t handle, to ensure than an application is resilient to spikes in the number of requests. any request that is processed by an application consumes resources like CPU, memory, IO, and so on. If requests come at a rate that exceeds an application’s available resources, the app may become unresponsive, behave inconsistently, or crash.
• Retry – enable an application to handle transient failures when it tries to connect to a service or network resource, by transparently retrying a failed operation.
• Timeout – wait for a predetermined length of time and take alternative action if that time is exceeded.
• Circuit Breaker – when connecting to a remote service or resource, handle faults that might take a variable amount of time to recover from.
• Bounded Queue – limit request queue sizes in front of heavily used resources.