Remote Events migrated from Spring Bus to Spring Cloud Stream (#2563)

* Remote Events migrated from Spring Bus to Spring Cloud Stream

---------

Co-authored-by: vasilchev <vasil.ilchev@bosch.com>

site/content/guides/clustering.md

@@ -15,18 +15,65 @@ the [hawkBit runtimes's README](https://github.com/eclipse-hawkbit/hawkbit/blob/
 
 ## Events
 
-Event communication between nodes is based on [Spring Cloud Bus](https://cloud.spring.io/spring-cloud-bus/)
-and [Spring Cloud Stream](http://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/). There are
-different [binder implementations](http://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/#_binders)
-available. The _hawkbit Update Server_ uses RabbitMQ binder. Every node gets his own queue to receive cluster events,
-the default payload is JSON.
-If an event is thrown locally at one node, it will be automatically delivered to all other available nodes via the
-Spring Cloud Bus's topic exchange:
+Event communication between nodes is based on  [Spring Cloud Stream](http://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/). 
+There are different [binder implementations](http://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/#_binders)
+available. The _hawkbit Update Server_ uses RabbitMQ binder.
 
-![](../../images/eventing-within-cluster.png)
+You can run multiple instances of any micro-service, including those consuming events.
+However, the `hawkbit-mgmt-server` should typically be run as a single instance, as it schedules time-sensitive jobs such as auto-assignment checking and rollout execution.
+If multiple management server instances are needed, you must extend hawkBit to ensure that scheduled tasks do not run concurrently.
+Alternatively, configure all but one instance to disable scheduler execution.
 
-Via the ServiceMatcher you can check whether an event happened locally at one node or on a different node.
-`serviceMatcher.isFromSelf(event)`
+## Event Channel Types in Spring Cloud Stream
+
+Remote events in hawkBit are distributed through **two distinct types of channels**:
+
+### 1. Fanout Event Channel
+
+- Every service instance listening to `fanoutEventChannel` receives **a copy of every message**, regardless of instance count.
+- Common for events that should be processed by each consumer independently
+    - In-memory cache updates
+    - Internal state propagation
+    - Logging or auditing
+- Not recommended for scenarios where only one consumer should process an event (see `serviceEventChannel` for that).
+
+**Note**: Every instance bound to this channel will get its own copy of the message.
+
+### 2. Service Event Channel
+
+The `serviceEventChannel` is used to **ensure exclusive consumption of events** across service instances.
+Only **one instance per consumer group** receives and processes each message, which is critical for non-idempotent or resource-sensitive operations.
+
+- Only one instance in a consumer group receives each message.
+- Ideal for external integrations, third-party API calls, or any task that must not be duplicated.
+- Load-balanced across instances within the same group.
+
+
+### Optional Protostuff for Spring cloud stream
+
+The micro-service instances are configured to communicate via Spring Cloud Stream. Optionally, you could
+use [Protostuff](https://github.com/protostuff/protostuff) based message payload serialization for improved performance.
+
+**Note**: If Protostuff is enabled it shall be enabled on all microservices!
+
+Add/Uncomment to/in your `application.properties` :
+
+```properties
+spring.cloud.stream.default.content-type=application/binary+protostuff
+```
+
+Add to your `pom.xml` :
+
+```xml
+<dependency>
+    <groupId>io.protostuff</groupId>
+    <artifactId>protostuff-core</artifactId>
+</dependency>
+<dependency>
+    <groupId>io.protostuff</groupId>
+    <artifactId>protostuff-runtime</artifactId>
+</dependency>
+```
 
 ## Caching