docs: update decoupling via messaging

radar/2017-03-01/decoupling-infrastructure-via-messaging.md

@@ -1,14 +0,0 @@
----
-title:      "Decoupling Infrastructure via Messaging"
-ring:       trial
-quadrant:   methods-and-patterns
----
-
-In [Microservices](/methods-and-patterns/microservices/) we have already covered the trend that modern architectures are moving away more and more from big monolithic applications to distributed software suites.
-The result of splitting our software and infrastructure in smaller parts, is the need to communicate with each other.
-This can be done by direct communication or by message-based asynchronouous communication.
-While synchronuous communication allows for more plannable "real-time" response times of the overall systems, asynchronouos communication increases the resilience and stability of the system significantly and allows one to use other integration and scaling patterns. However, it often comes with additional complexity.
-
-Most of the IaaS Cloud providers offer messaging services such as AWS SQS which provide the possibility to decouple our infrastructure via Messaging.
-Also, we use [RabbitMQ](/tools/rabbitmq/) as a Messaging and Broker solution within our applications.
-The decision of using messaging and messaging patterns as an integration strategy can be made as part of [strategic design](/methods-and-patterns/strategic-domain-driven-design/) considerations.

radar/2017-03-01/decoupling-via-messaging.md

@@ -0,0 +1,12 @@
+---
+title:      "Decoupling via Messaging"
+ring:       trial
+quadrant:   methods-and-patterns
+tags:       [architecture, devops]
+---
+
+In [Microservices](/methods-and-patterns/microservices/), we have already covered the trend that modern architectures are moving away from big monolithic applications to distributed software suites. The result of splitting our software and infrastructure into smaller parts is the need for these parts to communicate with each other. This can be done through direct communication or message-based asynchronous communication.
+
+While synchronous communication allows for more predictable "real-time" response times of the overall systems, asynchronous communication significantly increases the resilience and stability of the system and allows for the use of other integration and scaling patterns. However, it often comes with additional complexity.
+
+Most IaaS Cloud providers offer messaging services, such as [AWS SQS](https://aws.amazon.com/sqs/), which provide the possibility to decouple our infrastructure via messaging. Additionally, we use [RabbitMQ](/tools/rabbitmq/) as a messaging and broker solution within our applications. The decision to use messaging and messaging patterns as an integration strategy can be made as part of [strategic design](/methods-and-patterns/strategic-domain-driven-design/) considerations.

radar/2017-03-01/rabbitmq.md

@@ -8,6 +8,6 @@ RabbitMQ is an Open Source message broker - implementing the Advanced Message Qu
 
 There are several alternative solutions to RabbitMQ, e. g. the free Apache ActiveMQ, which is integrated in [Anypoint platform](/tools/anypoint-platform/). ActiveMQ implements a somewhat simpler routing concept than RabbitMQ, but offers more protocols. Commercial products in this area are offered by IBM (Websphere MQ), Fiorano and almost every vendor of ESB products.
 
-We use RabbitMQ internally for transferring messages safely in our logging ecosystem between [Logstash](/platforms-and-aoe-services/elk-stack/) proxies and servers using direct and fan-out exchanges for delivering messages to appropriate destinations. RabbitMQ is also used to asynchronously trigger Jenkins jobs from our SCMs to mitigate heavy load on the SCMs, usually caused by Jenkins polls for SCM changes. Additionally, some critical events for monitoring are using RabbitMQ for guaranteed notification. 
+We use RabbitMQ internally for transferring messages safely in our logging ecosystem between [Logstash](/platforms-and-aoe-services/elk-stack/) proxies and servers using direct and fan-out exchanges for delivering messages to appropriate destinations. RabbitMQ is also used to asynchronously trigger Jenkins jobs from our SCMs to mitigate heavy load on the SCMs, usually caused by Jenkins polls for SCM changes. Additionally, some critical events for monitoring are using RabbitMQ for guaranteed notification.
 
-RabbitMQ is rated "Trial". It fits into our approach to build robust, [resilient systems](/methods-and-patterns/resilience-thinking/) and use [asynchronous messages](/methods-and-patterns/decoupling-infrastructure-via-messaging/) for loosely coupled communications between components. In practice, RabbitMQ proved to be stable and dealt well with service interruptions from failures and maintenance slots. A common pain point is RabbitMQ as a single point of failure disrupting the data flow in a system. This issue is currently approached by setting up a HA cluster for RabbitMQ. The outcome of this approach will clarify the extent of future usage of RabbitMQ in our systems.
+RabbitMQ is rated "Trial". It fits into our approach to build robust, [resilient systems](/methods-and-patterns/resilience-thinking/) and use [asynchronous messages](/methods-and-patterns/decoupling-via-messaging/) for loosely coupled communications between components. In practice, RabbitMQ proved to be stable and dealt well with service interruptions from failures and maintenance slots. A common pain point is RabbitMQ as a single point of failure disrupting the data flow in a system. This issue is currently approached by setting up a HA cluster for RabbitMQ. The outcome of this approach will clarify the extent of future usage of RabbitMQ in our systems.

radar/2017-03-01/resilience-thinking.md

@@ -2,6 +2,7 @@
 title:      "Resilience Thinking"
 ring:       trial
 quadrant:   methods-and-patterns
+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.
@@ -11,8 +12,8 @@ There are a lot of different resilience patterns and it is also a matter of the
 *   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/))
+*   Use Message-based communication where useful ([Decoupling via Messaging](/methods-and-patterns/decoupling-via-messaging/))
 *   Use Circuit Breaker to Isolate errors and allow system 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.
+"Embrace Errors" should be the mindset - because it is not a question if errors appear - it's just a question of when.

radar/2019-11-01/decoupling-infrastructure-via-messaging.md

@@ -1,6 +0,0 @@
----
-title:      "Decoupling Infrastructure via Messaging"
-ring:       trial
-quadrant:   methods-and-patterns
-featured:   false
----

radar/2019-11-01/decoupling-via-messaging.md

@@ -0,0 +1,8 @@
+---
+title:      "Decoupling via Messaging"
+ring:       adopt
+quadrant:   methods-and-patterns
+tags:       [architecture, devops]
+---
+
+Updated to "adopt"

radar/2022-03-28/resilience-thinking.md

@@ -19,7 +19,7 @@ patterns and methods used are:
 * 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/))
+* Use message-based communication where useful ([Decoupling via Messaging](/methods-and-patterns/decoupling-via-messaging/))
 * 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

radar/2024-06-01/decoupling-via-messaging.md

@@ -0,0 +1,15 @@
+---
+title:      "Decoupling via Messaging"
+ring:       adopt
+quadrant:   methods-and-patterns
+tags:       [architecture, devops]
+featured:   false
+---
+
+In recent years, messaging systems have become more robust, scalable, and easier to integrate with existing applications. This has increased the importance of messaging in modern software architectures, making it an essential strategy for decoupling components and ensuring the resilience and stability of distributed systems:
+
+- **Event Streaming**: Platforms such as [Apache Kafka](/tools/kafka/) have evolved significantly to handle massive data streams with enhanced reliability and integration capabilities.
+
+- **Serverless Messaging**: The rise of [serverless computing](/methods-and-patterns/serverless/) has simplified the creation of scalable, event-driven architectures, allowing developers to build complex workflows and event-processing pipelines without the overhead of managing infrastructure.
+
+- **Advanced Observability**: Improved tools for monitoring and managing messaging systems now offer detailed insights into message flows and system performance, enabling faster diagnosis and resolution of issues.