AJR/TechradarDev
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: fix some more spelling issues (#167)

Browse Source
This commit is contained in:
Stefan Rotsch
2023-02-22 19:40:39 +01:00
committed by Bastian
parent dd2e4e71c0
commit 94f368249e
10 changed files with 65 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
radar/2022-03-28/resilience-thinking.md
View File

@@ -2,18 +2,26 @@
title: "Resilience Thinking"
ring: adopt
quadrant: methods-and-patterns
tags: [architecture]
tags: [architecture]
---
Resilience is the capability of an application or service to resist different error scenarios. Especially for distributed systems - where a lot of communication between different services happen - it's very important to explicitly think of implementing resilience.
Resilience is the capability of an application or service to resist different error scenarios. Especially for
distributed systems - where a lot of communication between different services happen - it's very important to explicitly
think of implementing resilience.
There are a lot of different resilience patterns and it is also a matter of the overall software design. Typical patterns and methods used are:
There are a lot of different resilience patterns, and it is also a matter of the overall software design. Typical
patterns and methods used are:
* Do not hide API calls or any other external communication in your application (for example with unnecessary abstraction) - instead make it explicit that an external communication happens - e.g. by using the Facade Pattern. On the one hand, this makes it obvious that a potential slow and error prone communication is going to happen, and it makes it easier to implement error handling.
* Detect errors explicitly: Check the response message format and configure proper timeouts for external communication
* Handle errors in a smart way: Show a nice error message to your customer or, even better, graceful degrade features - e.g. by showing some fallback text
* Use message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging.html))
* Use circuit breakers to isolate errors and allow systems to recover
* Use short activation paths in your strategic architecture - so that there is only a minimal set of communications between your services required for certain features or business requests
* Do not hide API calls or any other external communication in your application (for example with unnecessary
abstraction) - instead make it explicit that an external communication happens - e.g. by using the Facade Pattern. On
the one hand, this makes it obvious that a potential slow and error-prone communication is going to happen, and it
makes it easier to implement error handling.
* Detect errors explicitly: Check the response message format and configure proper timeouts for external communication
* Handle errors in a smart way: Show a nice error message to your customer or, even better, graceful degrade features -
e.g. by showing some fallback text
* Use message-based communication where useful ([Decoupling Infrastructure via Messaging](/methods-and-patterns/decoupling-infrastructure-via-messaging.html))
* Use circuit breakers to isolate errors and allow systems to recover
* Use short activation paths in your strategic architecture - so that there is only a minimal set of communications
between your services required for certain features or business requests
"Embrace Errors" should be the mindset - because it is not a question if errors appear - it's just a question of when.