DOC-3967 moved transaction and pipeline pages to reference section

andy-stark-redis · andy-stark-redis · commit 6ab6b8e9b904 · 2025-07-01T11:26:22.000+01:00
diff --git a/content/commands/command.md b/content/commands/command.md
@@ -101,7 +101,7 @@ Command flags are an array. It can contain the following simple strings (status
 * **no_auth:** executing the command doesn't require authentication.
 * **no_async_loading:** the command is denied during asynchronous loading (that is when a replica uses disk-less `SWAPDB SYNC`, and allows access to the old dataset).
 * **no_mandatory_keys:** the command may accept key name arguments, but these aren't mandatory.
-* **no_multi:** the command isn't allowed inside the context of a [transaction]({{< relref "/develop/interact/transactions" >}}).
+* **no_multi:** the command isn't allowed inside the context of a [transaction]({{< relref "/develop/reference/transactions" >}}).
 * **noscript:** the command can't be called from [scripts]({{< relref "/develop/interact/programmability/eval-intro" >}}) or [functions]({{< relref "/develop/interact/programmability/functions-intro" >}}).
 * **pubsub:** the command is related to [Redis Pub/Sub]({{< relref "/develop/interact/pubsub" >}}).
 * **random**: the command returns random results, which is a concern with verbatim script replication.
diff --git a/content/develop/clients/dotnet/condexec.md b/content/develop/clients/dotnet/condexec.md
@@ -17,7 +17,7 @@ weight: 60
 
 Most Redis client libraries use transactions with the
 [`WATCH`]({{< relref "/commands/watch" >}}) command as the main way to prevent
-two clients writing to the same key at once (see [Transactions]({{< relref "/develop/interact/transactions" >}}) for more information). Unfortunately, this approach is
+two clients writing to the same key at once (see [Transactions]({{< relref "/develop/reference/transactions" >}}) for more information). Unfortunately, this approach is
 difficult to use explicitly in `NRedisStack`. Its
 [multiplexing]({{< relref "/develop/clients/pools-and-muxing" >}}) system
 is highly efficient and convenient but can also cause bad interactions
diff --git a/content/develop/clients/dotnet/transpipe.md b/content/develop/clients/dotnet/transpipe.md
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/use/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/interact/transactions" >}})
+    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -57,7 +57,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/interact/transactions" >}})
+[Transactions]({{< relref "/develop/reference/transactions" >}})
 for more information about optimistic locking.
 
 The approach to optimistic locking that other clients use
diff --git a/content/develop/clients/go/transpipe.md b/content/develop/clients/go/transpipe.md
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/use/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/interact/transactions" >}})
+    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -77,7 +77,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/interact/transactions" >}})
+[Transactions]({{< relref "/develop/reference/transactions" >}})
 for more information about optimistic locking.
 
 The code below reads a string
diff --git a/content/develop/clients/hiredis/transpipe.md b/content/develop/clients/hiredis/transpipe.md
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/use/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/interact/transactions" >}})
+    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -109,5 +109,5 @@ when you have finished processing it, as in the example above.
 you can implement them yourself using the [`MULTI`]({{< relref "/commands/multi" >}}),
 [`EXEC`]({{< relref "/commands/exec" >}}), and [`WATCH`]({{< relref "/commands/watch" >}})
 commands as you would from [`redis-cli`]({{< relref "/develop/tools/cli" >}}).
-See [Transactions]({{< relref "/develop/interact/transactions" >}})
+See [Transactions]({{< relref "/develop/reference/transactions" >}})
 for more information.
diff --git a/content/develop/clients/jedis/transpipe.md b/content/develop/clients/jedis/transpipe.md
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/use/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/interact/transactions" >}})
+    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -68,7 +68,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/interact/transactions" >}})
+[Transactions]({{< relref "/develop/reference/transactions" >}})
 for more information about optimistic locking.
 
 The code below reads a string
diff --git a/content/develop/clients/nodejs/transpipe.md b/content/develop/clients/nodejs/transpipe.md
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/use/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/interact/transactions" >}})
+    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -112,7 +112,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/interact/transactions" >}})
+[Transactions]({{< relref "/develop/reference/transactions" >}})
 for more information about optimistic locking.
 
 The code below reads a string
diff --git a/content/develop/clients/pools-and-muxing.md b/content/develop/clients/pools-and-muxing.md
@@ -71,7 +71,7 @@ used to identify where to send the response data from your commands.
 
 Note that it is not a problem if the multiplexer receives several commands close
 together in time. When this happens, the multiplexer can often combine the commands into a
-[pipeline]({{< relref "/develop/use/pipelining" >}}), which
+[pipeline]({{< relref "/develop/reference/pipelining" >}}), which
 improves efficiency.
 
 Multiplexing offers high efficiency but works transparently without requiring
diff --git a/content/develop/clients/redis-py/transpipe.md b/content/develop/clients/redis-py/transpipe.md
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/use/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/interact/transactions" >}})
+    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -62,7 +62,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/interact/transactions" >}})
+[Transactions]({{< relref "/develop/reference/transactions" >}})
 for more information about optimistic locking.
 
 The example below shows how to repeatedly attempt a transaction with a watched
diff --git a/content/develop/get-started/vector-database.md b/content/develop/get-started/vector-database.md
@@ -120,7 +120,7 @@ Inspect the structure of one of the bike JSON documents:
 {{< clients-example search_vss dump_data />}}
 
 ### 2. Store the demo data in Redis
-Now iterate over the `bikes`  array to store the data as [JSON]({{< relref "/develop/data-types/json/" >}}) documents in Redis by using the [JSON.SET]({{< relref "commands/json.set/" >}}) command. The below code uses a [pipeline]({{< relref "/develop/use/pipelining" >}}) to minimize the network round-trip times:
+Now iterate over the `bikes`  array to store the data as [JSON]({{< relref "/develop/data-types/json/" >}}) documents in Redis by using the [JSON.SET]({{< relref "commands/json.set/" >}}) command. The below code uses a [pipeline]({{< relref "/develop/reference/pipelining" >}}) to minimize the network round-trip times:
 
 {{< clients-example search_vss load_data />}}
 
diff --git a/content/develop/interact/programmability/_index.md b/content/develop/interact/programmability/_index.md
@@ -60,7 +60,7 @@ Please refer to the following pages for more information:
 * [Redis Functions]({{< relref "/develop/interact/programmability/functions-intro" >}})
 
 When running a script or a function, Redis guarantees its atomic execution.
-The script's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "/develop/interact/transactions" >}}).
+The script's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "/develop/reference/transactions" >}}).
 These semantics mean that all of the script's effects either have yet to happen or had already happened.
 The blocking semantics of an executed script apply to all connected clients at all times.
 
diff --git a/content/develop/interact/programmability/eval-intro.md b/content/develop/interact/programmability/eval-intro.md
@@ -190,7 +190,7 @@ Please consult your client's documentation regarding the specific details.
 
 ### `EVALSHA` in the context of pipelining
 
-Special care should be given executing [`EVALSHA`]({{< relref "/commands/evalsha" >}}) in the context of a [pipelined request]({{< relref "/develop/use/pipelining" >}}).
+Special care should be given executing [`EVALSHA`]({{< relref "/commands/evalsha" >}}) in the context of a [pipelined request]({{< relref "/develop/reference/pipelining" >}}).
 The commands in a pipelined request run in the order they are sent, but other clients' commands may be interleaved for execution between these.
 Because of that, the `NOSCRIPT` error can return from a pipelined request but can't be handled.
 
@@ -228,7 +228,7 @@ These are:
   _1_ means the specific SHA1 is recognized as a script already present in the scripting cache. _0_'s meaning is that a script with this SHA1 wasn't loaded before (or at least never since the latest call to [`SCRIPT FLUSH`]({{< relref "/commands/script-flush" >}})).
 
 * `SCRIPT LOAD script`: this command registers the specified script in the Redis script cache. 
-  It is a useful command in all the contexts where we want to ensure that [`EVALSHA`]({{< relref "/commands/evalsha" >}}) doesn't not fail (for instance, in a pipeline or when called from a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "/develop/interact/transactions" >}}), without the need to execute the script.
+  It is a useful command in all the contexts where we want to ensure that [`EVALSHA`]({{< relref "/commands/evalsha" >}}) doesn't not fail (for instance, in a pipeline or when called from a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "/develop/reference/transactions" >}}), without the need to execute the script.
 
 * [`SCRIPT KILL`]({{< relref "/commands/script-kill" >}}): this command is the only way to interrupt a long-running script (a.k.a slow script), short of shutting down the server.
   A script is deemed as slow once its execution's duration exceeds the configured [maximum execution time]({{< relref "/develop/interact/programmability/#maximum-execution-time" >}}) threshold.
@@ -270,7 +270,7 @@ We call this **script effects replication**.
 starting with Redis 5.0, script effects replication is the default mode and does not need to be explicitly enabled.
 
 In this replication mode, while Lua scripts are executed, Redis collects all the commands executed by the Lua scripting engine that actually modify the dataset.
-When the script execution finishes, the sequence of commands that the script generated are wrapped into a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "/develop/interact/transactions" >}}) and are sent to the replicas and AOF.
+When the script execution finishes, the sequence of commands that the script generated are wrapped into a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "/develop/reference/transactions" >}}) and are sent to the replicas and AOF.
 
 This is useful in several ways depending on the use case:
 
diff --git a/content/develop/interact/programmability/functions-intro.md b/content/develop/interact/programmability/functions-intro.md
@@ -36,7 +36,7 @@ The underlying assumption is that scripts are a part of the application and not
 This approach suits many light-weight scripting use cases, but introduces several difficulties once an application becomes complex and relies more heavily on scripting, namely:
 
 1. All client application instances must maintain a copy of all scripts. That means having some mechanism that applies script updates to all of the application's instances.
-1. Calling cached scripts within the context of a [transaction]({{< relref "/develop/interact/transactions" >}}) increases the probability of the transaction failing because of a missing script. Being more likely to fail makes using cached scripts as building blocks of workflows less attractive.
+1. Calling cached scripts within the context of a [transaction]({{< relref "/develop/reference/transactions" >}}) increases the probability of the transaction failing because of a missing script. Being more likely to fail makes using cached scripts as building blocks of workflows less attractive.
 1. SHA1 digests are meaningless, making debugging the system extremely hard (e.g., in a [`MONITOR`]({{< relref "/commands/monitor" >}}) session).
 1. When used naively, [`EVAL`]({{< relref "/commands/eval" >}}) promotes an anti-pattern in which scripts the client application renders verbatim scripts instead of responsibly using the [`KEYS` and `ARGV` Lua APIs]({{< relref "develop/interact/programmability/lua-api#runtime-globals" >}}).
 1. Because they are ephemeral, a script can't call another script. This makes sharing and reusing code between scripts nearly impossible, short of client-side preprocessing (see the first point).
@@ -81,7 +81,7 @@ Functions are also persisted to the AOF file and replicated from master to repli
 When Redis is used as an ephemeral cache, additional mechanisms (described below) are required to make functions more durable.
 
 Like all other operations in Redis, the execution of a function is atomic.
-A function's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "/develop/interact/transactions" >}}).
+A function's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "/develop/reference/transactions" >}}).
 These semantics mean that all of the script's effects either have yet to happen or had already happened.
 The blocking semantics of an executed function apply to all connected clients at all times.
 Because running a function blocks the Redis server, functions are meant to finish executing quickly, so you should avoid using long-running functions.
diff --git a/content/develop/reference/pipelining.md b/content/develop/reference/pipelining.md
@@ -100,7 +100,7 @@ call. Consequently, the number of total queries performed per second
 initially increases almost linearly with longer pipelines, and eventually
 reaches 10 times the baseline obtained without pipelining, as shown in this figure.
 
-![Pipeline size and IOPs](pipeline_iops.png)
+{{< image filename="/images/dev/reference/pipeline_iops.webp" alt="Pipeline size and IOPs" >}}
 
 ## A real world code example
 
diff --git a/content/develop/reference/protocol-spec.md b/content/develop/reference/protocol-spec.md
@@ -696,7 +696,7 @@ Pipelining is supported, so multiple commands can be sent with a single write op
 The client can skip reading replies and continue to send the commands one after the other.
 All the replies can be read at the end.
 
-For more information, see [Pipelining]({{< relref "/develop/use/pipelining" >}}).
+For more information, see [Pipelining]({{< relref "/develop/reference/pipelining" >}}).
 
 ## Inline commands
 Sometimes you may need to send a command to the Redis server but only have `telnet` available.
diff --git a/content/develop/reference/transactions.md b/content/develop/reference/transactions.md
@@ -9,6 +9,7 @@ categories:
 - oss
 - kubernetes
 - clients
+- aliases: /develop/interact/transactions
 description: How transactions work in Redis
 linkTitle: Transactions
 title: Transactions
diff --git a/content/develop/use/pipelining/pipeline_iops.png b/content/develop/use/pipelining/pipeline_iops.png
diff --git a/content/embeds/r7.2-breaking-changes.md b/content/embeds/r7.2-breaking-changes.md
@@ -19,7 +19,7 @@ Upgrading to Redis version 7.2 from version 7.0 introduces the following potenti
 
 - Time sampling is now frozen during command execution and scripts ([#10300](https://github.com/redis/redis/pull/10300)). While a command or script is running, the keys used by the command or script will not expire. This breaks any script that uses a loop to wait for a key to expire. 
 
-- Blocked commands in scripts now work the same way as when they are used in [transactions]({{< relref "/develop/interact/transactions" >}}) ([#11568](https://github.com/redis/redis/pull/11568)). 
+- Blocked commands in scripts now work the same way as when they are used in [transactions]({{< relref "/develop/reference/transactions" >}}) ([#11568](https://github.com/redis/redis/pull/11568)). 
 
 ##### Error handling
 
diff --git a/content/embeds/r7.2-combined-breaking-changes.md b/content/embeds/r7.2-combined-breaking-changes.md
diff --git a/content/operate/rc/databases/configuration/sizing.md b/content/operate/rc/databases/configuration/sizing.md
diff --git a/static/images/dev/reference/pipeline_iops.webp b/static/images/dev/reference/pipeline_iops.webp
