fix(influxdb3): Data durability, data flow

1. Maintains the higher-level structure
2. Uses the bulleted list format for clarity
3. Adds the detailed explanations from the original Data flow section as Details items
4. Uses sentence case for all headings
5. Numbers the sections to match the original flow diagram

Author: jstirnaman

content/influxdb3/core/reference/internals/durability/_index.md

@@ -8,7 +8,7 @@ menu:
     parent: Core internals
     name: Data durability
 weight: 200
-source: /content/shared/influxdb3-internals-reference/durability/_index.md
+source: /shared/influxdb3-internals-reference/durability.md
 ---
 
 <!--

content/influxdb3/enterprise/reference/internals/_index.md

@@ -7,7 +7,7 @@ menu:
     name: Enterprise internals
     parent: Reference
 weight: 107
-source: /content/shared/influxdb3-internals-reference/_index.md
+source: /shared/influxdb3-internals-reference/_index.md
 ---
 
 <!--

content/influxdb3/enterprise/reference/internals/durability/_index.md

@@ -8,7 +8,7 @@ menu:
     parent: Enterprise internals
     name: Data durability
 weight: 200
-source: /content/shared/influxdb3-internals-reference/durability.md
+source: /shared/influxdb3-internals-reference/durability.md
 ---
 
 <!--

content/shared/influxdb3-internals-reference/durability.md

@@ -1,78 +1,50 @@
-## How data flows through InfluxDB 3
+## How data flows through {{% product-name %}}
 
 When data is written to {{% product-name %}}, it progresses through multiple stages to ensure durability, optimize performance, and enable efficient querying. Configuration options at each stage affect system behavior, balancing reliability and resource usage.
 
-### Write Path Overview
-
-{{% product-name %}} processes data through several stages to ensure durability, query performance, and efficient storage. Below is a high-level overview of these stages:
-
-1. [Write validation](#write-validation)
-
-2. [Memory buffer](#memory-buffer) 
-
-3. [Write-Ahead Log (WAL) persistence](#wal-persistence)
-
-4. [Queryable buffer](#query-availability) 
-
-5. [Parquet storage](#parquet-storage) 
-
-6. [In-memory cache](#in-memory-cache) 
-
-
-##### Write Validation
-
-- Process: InfluxDB validates incoming data before accepting it into the system.
-     
-- Impact: Prevents malformed or unsupported data from entering the database.
-
-##### Memory Buffer
-
-- Process: Incoming writes are stored in an in-memory buffer before persistence.
-
-- Impact: Increases ingestion efficiency by allowing batch processing.
-
-- Tradeoff: Larger batches improve throughput but require more memory.
-
-##### WAL Persistence
-
-- Process: The system flushes the write buffer to the WAL every second (default).
-
-- Impact: Ensures durability by persisting data to object storage.
-
-- Tradeoff: More frequent flushing improves durability but increases I/O overhead.
-
-##### Query Availability
-
-- Process: The system moves data to the queryable buffer after WAL persistence.
+## Data flow
 
-- Impact: Enables fast queries on recent data.
+As data moves through {{% product-name %}}, it follows a structured path to ensure durability, efficient querying, and optimized storage.
 
-- Tradeoff: A larger buffer speeds up queries but increases memory usage.
+The figure below shows how written data flows through the database.
 
-##### Parquet Storage
+{{< img-hd src="/img/influxdb/influxdb-3-write-path.png" alt="Write Path for InfluxDB 3 Core & Enterprise" />}}
 
-- Process: Every ten minutes (default), data is persisted to Parquet files in object storage.
+1. [Write validation and memory buffer](#1-write-validation-and-memory-buffer)
+2. [Write-ahead log (WAL) persistence](#2-write-ahead-log-wal-persistence)
+3. [Query availability](#3-query-availability)
+4. [Parquet storage](#4-parquet-storage)
+5. [In-memory cache](#5-in-memory-cache)
 
-- Impact: Provides durable, long-term storage.
+### Write validation and memory buffer
 
-- Tradeoff: More frequent persistence reduces reliance on the WAL but increases I/O costs.
+- **Process**: InfluxDB validates incoming data before accepting it into the system.
+- **Impact**: Prevents malformed or unsupported data from entering the database.
+- **Details**: The system validates incoming data and stores it in the write buffer (in memory). If [`no_sync=true`](#no-sync-write-option), the server sends a response to acknowledge the write.
 
-##### In-Memory Cache
+### Write-ahead log (WAL) persistence
 
-- Process: Recently persisted Parquet files are cached in memory.
+- **Process**: The system flushes the write buffer to the WAL every second (default).
+- **Impact**: Ensures durability by persisting data to object storage.
+- **Tradeoff**: More frequent flushing improves durability but increases I/O overhead.
+- **Details**: Every second (default), the system flushes the write buffer to the Write-Ahead Log (WAL) for persistence in the Object store. If [`no_sync=false`](#no-sync-write-option) (default), the server sends a response to acknowledge the write.
 
-- Impact: Reduces query latency by minimizing object storage access.
+### Query availability
 
-## Data flow
+- **Process**: The system moves data to the queryable buffer after WAL persistence.
+- **Impact**: Enables fast queries on recent data.
+- **Tradeoff**: A larger buffer speeds up queries but increases memory usage.
+- **Details**: After WAL persistence completes, data moves to the queryable buffer where it becomes available for queries. By default, the server keeps up to 900 WAL files (15 minutes of data) buffered.
 
-As data moves through InfluxDB 3, it follows a structured path to ensure durability, efficient querying, and optimized storage. 
+### Parquet storage
 
-The figure below shows how written data flows through the database.
+- **Process**: Every ten minutes (default), data is persisted to Parquet files in object storage.
+- **Impact**: Provides durable, long-term storage.
+- **Tradeoff**: More frequent persistence reduces reliance on the WAL but increases I/O costs.
+- **Details**: Every ten minutes (default), the system persists the oldest data from the queryable buffer to the Object store in Parquet format. InfluxDB keeps the remaining data (the most recent 5 minutes) in memory.
 
-{{< img-hd src="/img/influxdb/influxdb-3-write-path.png" alt="Write Path for InfluxDB 3 Core & Enterprise" />}}
+### In-memory cache
 
-1. **Incoming writes**: The system validates incoming data and stores it in the write buffer (in memory). If [`no_sync=true`](#no-sync-write-option), the server sends a response to acknowledge the write.
-2. **WAL flush**: Every second (default), the system flushes the write buffer to the Write-Ahead Log (WAL) for persistence in the Object store. If [`no_sync=false`](#no-sync-write-option) (default), the server sends a response to acknowledge the write.
-3. **Query availability**: After WAL persistence completes, data moves to the queryable buffer where it becomes available for queries. By default, the server keeps up to 900 WAL files (15 minutes of data) buffered.
-4. **Long-term storage in Parquet**: Every ten minutes (default), the system persists the oldest data from the queryable buffer to the Object store in Parquet format. InfluxDB keeps the remaining data (the most recent 5 minutes) in memory.
-5. **In-memory cache**: InfluxDB puts Parquet files into an in-memory cache so that queries against the most recently persisted data don't have to go to object storage.
+- **Process**: Recently persisted Parquet files are cached in memory.
+- **Impact**: Reduces query latency by minimizing object storage access.
+- **Details**: InfluxDB puts Parquet files into an in-memory cache so that queries against the most recently persisted data don't have to go to object storage.