Document benefits of using a dedicated transactional session processor endpoint (#7201)

* Document benefits of using a dedicated transactional session processor endpoint

* Update index_remote-processor_transactionalsession_[3.3,).partial.md

* Updates after feedback from Tim

* Wording

* Pull shared benefits out to a general section that applies to both scenarios

* Apply suggestions from code review

Co-authored-by: Poornima Nayar <[email protected]>

---------

Co-authored-by: Daniel Marbach <[email protected]>
Co-authored-by: Poornima Nayar <[email protected]>

Author: 3 people

nservicebus/transactional-session/index.md

@@ -77,6 +77,14 @@ The transactional session feature requires a supported persistence package to st
 * [MongoDB](/persistence/mongodb)
 * [DynamoDB](/persistence/dynamodb/)
 
+## Design considerations
+
+It's recommended to not mix the processing of control messages with business messages in order to get:
+
+- Predictable control message dispatch: Processing of control messages will be more reliable since there is no risk of getting delayed behind slow business messages
+- More accurate metrics: Metrics like critical time and queue length will accurately represent the performance of the control message processing and not be skewed by business messages
+- Simplified management: Knowing that the endpoint only processes control messages makes it possible to always retry all failed messages related to the endpoint via tools like ServicePulse
+
 ## Transaction consistency
 
 To guarantee atomic consistency across database and message operations, the transactional session requires the [outbox](/nservicebus/outbox) to be enabled. This combination of features provides the strongest consistency guarantees and is, therefore, the recommended, safe-by-default configuration.

nservicebus/transactional-session/index_remote-processor_transactionalsession_[3.3,).partial.md

@@ -13,6 +13,13 @@ The processor endpoint [must have both the outbox and the transactional session
 > [!NOTE]
 > If migrating to this mode from an endpoint couldn't be made send-only due to the previous limitations of the transactional session, see the migration guidance below.
 
+### Benefits
+
+Using the transactional session in send-only endpoints has the following benefits:
+
+- Simplified management: For short-lived endpoints, there is no longer a need to make sure that all control messages have been processed before decommissioning them 
+- Targeted scaling: Scaling can be tailored with only the load of control messages in mind since the incoming load to store the records are handled by the endpoint using the processor.                       
+
 ### Outbox cleanup
 
 For persisters where [Outbox cleanup](/nservicebus/outbox/#outbox-expiration-duration) is performed by the endpoint instances, only the remote processing endpoint should have the cleanup enabled to prevent concurrent cleanup from happening.