revert accidental change to sampling doc

content/en/docs/collector/deployment/multiple-collectors.md

@@ -20,10 +20,10 @@ report on the same data can lead to data loss or, at least, degraded data
 quality. In gateway collector deployments, applying this principle guards
 against sending inconsistent data to the backend. All metric data streams within
 OTLP must have a
-[single writer](/docs/specs/otel/metrics/data-model/#single-writer). In a system
-with multiple collectors, the single-writer principle is most relevant for
-receivers that create their own metrics, such a pull-based scrapers or a host
-metrics receiver.
+[single writer](/docs/specs/otel/metrics/data-model/#single-writer).
+In a system with multiple collectors, the single-writer principle is most
+relevant for receivers that create their own metrics, such a pull-based scrapers
+or a host metrics receiver.
 
 ### Deployment Considerations
 

content/en/docs/concepts/sampling/index.md

@@ -137,11 +137,3 @@ For the individual language specific implementations of the OpenTelemetry API &
 SDK you will find support for sampling at the respective documentation pages:
 
 {{% sampling-support-list " " %}}
-
-### Single-Writer Principle
-
- When scaling collectors for distributed tracing with tail sampling, it's important to consider 
-the Single-Writer Principle. This principle ensures a single logical writer makes sampling decisions for a
-particular trace, avoiding conflicts that might arise from multiple collectors evaluating the same trace for 
-sampling. Techniques like using load balancing exporters in front of tail-sampling collectors can help achieve this. 
-