feat(develop-docs): Add telemetry buffer page

develop-docs/sdk/telemetry/logs.mdx

@@ -396,7 +396,7 @@ A new data category for logs has been added to Relay, `log_item`. Both the `log`
 
 ### Buffering
 
-Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to use follow the [batch processor specification outlined](/sdk/telemetry/spans/batch-processor/) in the develop docs, but you should choose the approach that works best for your platform. When starting initial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 100 items, or if 5 seconds have passed.
+Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to follow the [telemetry buffer specification outlined](/sdk/telemetry/telemetry-buffer/) in the develop docs, but you should choose the approach that works best for your platform. When starting initial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 100 items, or if 5 seconds have passed.
 
 SDKS should NOT release logging capabilities to users if a buffering implementation has not been added to their SDK when adding logging APIs.
 

develop-docs/sdk/telemetry/spans/batch-processor.mdx → develop-docs/sdk/telemetry/telemetry-buffer.mdx

@@ -1,5 +1,7 @@
 ---
-title: Batch Processor
+title: Telemetry Buffer
+redirect_from:
+  - /sdk/telemetry/spans/batch-processor/
 ---
 
 <Alert level="warning">
@@ -10,6 +12,33 @@ title: Batch Processor
   This document uses key words such as "MUST", "SHOULD", and "MAY" as defined in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) to indicate requirement levels.
 </Alert>
 
+The telemetry buffer sits between the client and the transport, temporarily buffering high-volume telemetry data such as spans and logs. The client SHOULD continue to pass low-volume telemetry data, such as events, directly to the transport. The telemetry buffer aims to efficiently batch data to reduce the number of outgoing HTTP requests and Sentry envelopes. Without buffering, each span or log would trigger its own request, quickly overwhelming our backends.
+
+```mermaid
+flowchart LR
+  Client[Client] -->|high-volume telemetry data| Buffer[TelemetryBuffer]
+  Buffer -->|buffered telemetry data| Transport[Transport]
+  Client -->|low-volume telemetry data| Transport
+```
+
+Because telemetry workloads and platform constraints vary widely, buffer requirements differ across environments. For example, backend SDKs need high throughput and backpressure management to handle large data volumes. Mobile SDKs have lower throughput and don't need to worry much about backpressure, but they do need to minimize data loss in the event of abnormal process termination. Browser and GDX SDKs also have different requirements.
+
+Therefore, we recommend implementing different types of telemetry buffers tailored to the platform's needs. As of Nov 5th, 2025, this page is under development, and we're currently refining the requirements for different platforms:
+
+* [BatchProcessor V0](#batchprocessor-v0): The BatchProcessor V0 outlines the initial requirements, primarily for logs, to avoid sending numerous HTTP requests. This section exists only as a placeholder until we fully spec out the other telemetry buffers.
+* [Backend Telemetry Buffer](#backend-telemetry-buffer): To be defined
+* [Mobile Telemetry Buffer](#mobile-telemetry-buffer): To be defined
+* [Browser Telemetry Buffer](#browser-telemetry-buffer): To be defined
+* [GDX Telemetry Buffer](#gdx-telemetry-buffer): To be defined
+
+# Common Requirements
+
+To be defined. Things like common API, client reports, etc.
+
+# BatchProcessor V0
+
+## Overview
+
 The BatchProcessor batches spans and logs into one envelope to reduce the number of HTTP requests. When an SDK implements span streaming or logs, it MUST use a BatchProcessor, which is similar to [OpenTelemetry's Batch Processor](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/batchprocessor/README.md). The BatchProcessor holds logs and finished spans in memory and batches them together into envelopes. It uses a combination of time and size-based batching. When writing this, the BatchProcessor only handles spans and logs, but an SDK MAY use it for other telemetry data in the future.
 
 ## Specification
@@ -95,3 +124,19 @@ Scenario: 1 span added application crashes
   And loses the spans in the BatchProcessor
 
 ```
+
+# Backend Telemetry Buffer
+
+To be defined
+
+# Mobile Telemetry Buffer
+
+To be defined
+
+# Browser Telemetry Buffer
+
+To be defined
+
+# GDX Telemetry Buffer
+
+To be defined

redirects.js

@@ -74,6 +74,10 @@ const developerDocsRedirects = [
     source: '/sdk/replays/:path*',
     destination: '/sdk/telemetry/replays/:path*',
   },
+  {
+    source: '/sdk/telemetry/spans/batch-processor/',
+    destination: '/sdk/telemetry/telemetry-buffer/',
+  },
   {
     source: '/sdk/setup-wizards/:path*',
     destination: '/sdk/expected-features/setup-wizards/:path*',