update: Rename Redis to Aiven for Caching

.github/vale/styles/config/vocabularies/Aiven/accept.txt

@@ -111,6 +111,7 @@ Grafana
 Grafana/M
 GSuite
 hardcoded
+HAProxy
 HashiCorp
 Heatmap
 Hillyer

docs/platform/concepts/service_backups.md

@@ -57,7 +57,7 @@ backups with the appropriate tooling:
     `pgdump`
 -   [MySQL®](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html):
     `mysqldump`
--   [Redis®\*](https://redis.io/docs/connect/cli/#remote-backups-of-rdb-files):
+-   [Caching](https://redis.io/docs/connect/cli/#remote-backups-of-rdb-files):
     `redis-cli`
 -   [Cassandra®](https://docs.datastax.com/en/archived/cql/3.3/cql/cql_reference/cqlshCopy.html)
     `cqlsh`
@@ -115,7 +115,7 @@ data.
       <td>Single day backup</td>
     </tr>
     <tr>
-      <td>Aiven for Redis®*</td>
+      <td>Aiven for Caching</td>
       <td>Single backup only for disaster recovery</td>
       <td>Backup every 12 hours up to 1 day</td>
       <td>Backup every 12 hours up to 3 days</td>
@@ -268,17 +268,17 @@ point-in-time recovery (PITR) feature is currently not available.
 To be notified once the PITR feature is available for Cassandra, contact the Aiven support.
 :::
 
-### Aiven for Redis™\*
+### Aiven for Caching
 
-Aiven for Redis backups are taken every 12 hours.
+Aiven for Caching backups are taken every 12 hours.
 
 For persistence, Aiven supports Redis Database Backup (RDB).
 
 You can control the persistence feature using `redis_persistence` under
 **Advanced configuration** in [Aiven Console](https://console.aiven.io/)
 (the service's **Service settings** page):
 
-- When `redis_persistence` is set to `rdb`, Redis does RDB dumps every
+- When `redis_persistence` is set to `rdb`, Aiven for Caching does RDB dumps every
   10 minutes if any key is changed. Also, RDB dumps are done according
   to the backup schedule for backup purposes.
 - When `redis_persistence` is `off`, no RDB dumps or backups are done,
@@ -288,7 +288,7 @@ You can control the persistence feature using `redis_persistence` under
 
 :::note
 AOF persistence is currently not supported by Aiven for the managed
-Redis service.
+Aiven for Caching service.
 :::
 
 ### Aiven for ClickHouse®

docs/products/caching.md

@@ -0,0 +1,13 @@
+---
+title: Aiven for Caching
+---
+
+Aiven for Caching®, formerly known as Aiven for Redis®, is a fully managed in-memory NoSQL database. Deployable in the cloud of your choice, it helps you store and access data efficiently.
+
+For insights into he service name change and the latest updates, read the
+[blog post](https://aiven.io/blog/aiven-for-redis-becomes-aiven-for-caching).
+
+
+import DocCardList from '@theme/DocCardList';
+
+<DocCardList />

docs/products/redis/concepts/high-availability-redis.md → docs/products/caching/concepts/high-availability-redis.md

@@ -1,10 +1,11 @@
 ---
-title: High availability in Aiven for Redis®*
+title: High availability in Aiven for Caching
 ---
 
-Aiven for Redis®\* is available on a variety of plans, offering
-different levels of high availability. The selected plan defines the
-features available, and a summary is provided in the table below:
+Explore high availability with Aiven for Caching across multiple plans. Gain insights into service continuity and understand the approach to handling failures.
+
+Compare Aiven for Caching plans in the table below. Each plan offers unique
+configurations and features. Choose what best fits your needs.
 
 | Plan         | Node configuration                       | High availability & Backup features                                                                   | Backup history                                     |
 | ------------ | ---------------------------------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
@@ -14,7 +15,7 @@ features available, and a summary is provided in the table below:
 | **Premium**  | Three-node (primary + standby + standby) | Enhanced high availability with automatic failover among multiple standby nodes if the primary fails. | Automatic backups to a remote location.            |
 | **Custom**   | Custom configurations                    | Custom high availability and failover features based on user requirements.                            | Custom backup features based on user requirements. |
 
-Check out our [Plans & Pricing](https://aiven.io/pricing?product=redis)
+Refer to the [Plans & Pricing](https://aiven.io/pricing?product=redis)
 page for more information.
 
 ## Failure handling
@@ -34,37 +35,36 @@ page for more information.
     replacement node.
 
 :::note
-In case of database failover, your service's **Service URI** remains
-the same---only the IP address changes to point to the new primary node.
+In case of database failover, the **Service URI** remains unchanged, and only the IP address
+is updated to point to the new primary node.
 :::
 
 ## Highly available business, premium, and custom service plans
 
-If a standby Redis node fails, the primary node continues running
+If a standby Caching node fails, the primary node continues running
 normally, serving client applications without interruption. Once the
 replacement standby node is ready and synchronized with the primary, it
 begins real-time replication until the system stabilizes.
 
-When the failed node is a Redis primary, the combined information from
+When the failed node is a Caching primary, the combined information from
 the Aiven monitoring infrastructure and the standby node is used to make
 a failover decision. The standby node is promoted as the new primary and
 immediately serves clients. A new replacement node is automatically
 scheduled and becomes the new standby node.
 
 If both the primary and standby nodes fail simultaneously, new nodes
-will be created automatically to take their place as the new primary and
+are created automatically to take their place as the new primary and
 standby. However, this process involves some degree of data loss since
 the primary node is restored from the most recent backup available.
-Therefore, any writes made to the database since the last backup will be
-lost.
+Therefore, any writes made to the database since the last backup is lost.
 
 :::note
 The amount of time it takes to replace a failed node depends mainly on
 the used **cloud region** and the **amount of data** that needs to be
-restored. However, in the case of services with two or more node
-Business, Premium and Custom plans the surviving nodes will keep on
-serving clients even during the recreation of the other node. All of
-this is automatic and requires no administrator intervention.
+restored. However, in services with two or more nodes,
+such as business, premium, and custom plans, the surviving nodes continue serving
+clients even while recreating the other node. This is automatic and
+requires no administrator intervention.
 :::
 
 ## Single-node hobbyist and startup service plans
@@ -73,6 +73,5 @@ Losing the only node in the service triggers an automatic process of
 creating a new replacement node. The new node then restores its state
 from the latest available backup and resumes serving customers.
 
-Since there was just a single node providing the service, the service
-will be unavailable for the duration of the restore operation. All the
-write operations made since the last backup are lost.
+During the restore operation, the service is unavailable since there is only
+one node providing the service. Any write operations made after the last backup are lost.

docs/products/redis/concepts/lua-scripts-redis.md → docs/products/caching/concepts/lua-scripts-caching.md

@@ -1,15 +1,14 @@
 ---
-title: Lua scripts with Aiven for Redis®*
+title: Lua scripts with Aiven for Caching
 ---
 
-Learn how to leverage the inbuilt support for Lua scripting in Redis®\*
-using Aiven.
+Learn how to leverage the built-in support for Lua scripting in Aiven for Caching.
 
-Redis®\* has inbuilt support for running Lua scripts to perform various
+Aiven for Caching has inbuilt support for running Lua scripts to perform various
 actions directly on the Redis server. Scripting is typically controlled
 using the `EVAL`, `EVALSHA` and `SCRIPT LOAD` commands.
 
-For all newly-created Redis instances, `EVAL`, `EVALSHA` and
+For all newly created Aiven for Caching instances, `EVAL`, `EVALSHA` and
 `SCRIPT LOAD` commands are enabled by default.
 
 :::note

docs/products/caching/concepts/memory-usage.md

@@ -0,0 +1,133 @@
+---
+title: Memory Management and persistence in Aiven for Caching
+---
+
+Learn how Aiven for Caching, compatible with legacy Redis® OSS up to version 7.2.4, addresses the challenges of high memory usage and high change rate. Discover how it implements robust memory management and persistence strategies.
+
+Aiven for Caching functions primarily as a database cache. Data fetched from a database
+is stored in the caching system. Subsequent queries with the same parameters first check
+this cache, bypassing the need for a repeat database query. This efficiency can lead to
+challenges such as increased memory usage and frequent data changes, which
+Aiven for Caching is specifically designed to manage.
+
+
+## Data eviction policy in Aiven for Caching
+
+Data eviction policy is one of the most important caching settings and it
+is available in the Aiven Console.
+
+Aiven for Caching offers a `maxmemory` setting that determines the maximum amount
+of data that can be stored. The data eviction policy specifies what happens when this
+limit is reached. By default, all Aiven for Caching services have the eviction policy
+set to *No eviction*. If you continue storing data without removing anything, write
+operations fail once the maximum memory is reached.
+
+When data is consumed at a rate similar to how it is written, it is acceptable to use
+the current eviction policy. However, for other use cases, it is better to use
+the `allkeys-lru` eviction policy. This policy starts dropping the old keys based on
+the least recently used strategy when `maxmemory` is reached. Another way to handle
+the situation is to drop random keys.
+
+Regardless of the eviction policy chosen, the system will only drop the keys with an
+expiration time set, prioritizing keys with the shortest time-to-live (TTL).
+
+:::note
+If you continue to write data, you will eventually reach the `maxmemory` limit, regardless
+of the eviction policy you use.
+:::
+
+## High memory and high change rate behavior
+
+For all new Aiven for Caching services, the `maxmemory` setting is configured to **70% of
+available RAM** (minus management overhead) plus 10% for replication log.
+This configuration limits the memory usage to below 100%, accommodating operations
+that require additional memory:
+
+- When a new caching node connects to the master, the master node forks a copy of itself,
+  transmitting the current memory contents to the new node.
+- A similar forking process occurs when the state of the caching service is persisted to
+  disk, which for Aiven for Caching, happens **every 10 minutes**.
+
+:::note
+When a fork occurs, all memory pages of the new process are identical to
+the parent and do not consume extra memory. However, any changes in the parent process
+cause the memory configurations to diverge, increasing actual memory allocation.
+
+**Example**
+
+If the forked process took 4 minutes to perform the task, with new data
+written at 5 megabytes per second, the system memory usage can increase by approximately
+1.2 gigabytes during that time.
+:::
+
+The duration of backup and replication operations depends on the total amount
+f memory in use. As the size of the plan increases, the memory usage also increases,
+which can cause a memory divergence. Therefore, the amount of memory reserved for
+completing these operations without using a swap is directly proportional to the total
+memory available.
+
+If memory usage exceeds the available memory to the extent that a swap is required,
+the node may become unresponsive and require replacement.
+
+In scenarios involving on-disk persistence, the child process attempts to dump
+all its memory onto the disk. If the parent process undergoes significant changes and
+uses up available RAM, it may force the child process to swap unfinished memory pages
+to disk. This transition makes the child process more I/O bound and further slows its
+operation. Increased divergence from the parent process results in more frequent swapping,
+further slowing the process. In such cases, the node is limited to writing and reading
+from swap memory.
+
+The rate at which data can be written is influenced by the size of the data values
+and the specifics of the Aiven plan.
+
+:::tip
+Writing at about 5 megabytes per second is manageable in most situations. However,
+attempting to write at about 50 megabytes per second is likely lead to failures,
+particularly when memory usage approaches the allowed maximum or during the
+initialization of a new node.
+:::
+
+## Initial synchronization
+
+During system upgrades or in a high-availability setup in case of node failure,
+a new Caching node needs to be synchronized with the current master. The new node starts
+with an empty state, connects to the master, and requests a full copy of its current
+state. After receiving this copy, the new node begins following the replication stream
+from the master to achieve complete synchronization.
+
+Initial synchronization is CPU intensive, and because the underlying technology (Redis®)
+does not distribute the workload across multiple CPU cores, the maximum transfer speed is
+typically around 50 megabytes per second. Additionally, the new node initially persists
+data on disk, entering a separate loading phase with speeds in the low hundreds of
+megabytes per second. For a data set of 20 gigabytes, the initial sync phase takes
+about 6 minutes with today's hardware, and speed improvements are limited.
+
+Once initial synchronization is complete, the new node begins to follow the replication
+stream from the master. The size of the replication log is set to 10% of the total
+memory the underlying Redis technology can use. For a 28 gigabyte plan, this is just
+under 2 gigabytes.
+
+If the volume of changes during the 6 minute initial sync exceeds the replication
+log size, the new node cannot start following the replication stream and undergoes
+another initial sync.
+
+:::tip
+Writing new changes at 5 megabytes per second, totaling 1.8 gigabytes over 6 minutes,
+allows the new node to start up successfully. A higher constant rate of change can
+cause the synchronization to fail unless the replication log size is increased.
+:::
+
+## Mitigation
+
+Aiven does not impose a rate limit on traffic for Caching services because limiting only
+relevant write operations would require a specialized proxy, and restricting all traffic
+can negatively impact non-write operations.
+
+Rate limiting might be considered in the future, but for now, it is advisable to manage
+your workloads carefully and keep write rates moderate to prevent node failures due to
+excessive memory usage or challenges in initializing new nodes.
+
+:::note
+If you frequently need to write large volumes of data, contact Aiven support to
+discuss service configuration options that can accommodate your needs.
+:::

docs/products/caching/concepts/overview.md

@@ -0,0 +1,59 @@
+---
+title: Aiven for Caching overview
+---
+
+Aiven for Caching, a fully managed **in-memory NoSQL database**, offers efficient storage and quick data access in your preferred cloud. This service is compatible with legacy Redis® OSS up to version 7.2.4, facilitating seamless transitions and compatibility.
+
+For insights into he service name change and the latest updates, read the
+[blog post](https://aiven.io/blog/aiven-for-redis-becomes-aiven-for-caching).
+
+With Aiven, you can leverage the power of this in-memory database to improve the
+performance of your applications by setting up high-performance data caching.
+Additionally, it can be integrated seamlessly into your observability stack for
+purposes such as logging and monitoring.
+
+Aiven for Caching supports a wide range of data structures, including strings, hashes,
+lists, sets, sorted sets with range queries, bitmaps, hyperloglogs,
+geospatial indexes, and streams.
+
+## Features and benefits of Aiven for Caching
+
+Aiven for Caching has many features that make it easy and stress-free to
+use:
+
+-   **Managed service:** Fully managed service, so you don't have to worry about
+    setup, management, or updates. Aiven provides tools and integrations to help you
+    use this in-memory data store in your data pipelines.
+-   **Fast and easy deployment:** Launch a production-ready Redis-based service
+    within minutes. Choose from multiple public clouds across numerous global regions,
+    using high-performance clusters with optimally selected instance types and storage
+    options.
+-   **Integration with data infrastructure:** Aiven ensures secure
+    network connectivity using VPC peering, PrivateLink, or
+    TransitGateway technologies. Aiven integrates with various
+    observability tooling, including Datadog, Prometheus, and Jolokia,
+    or you can use Aiven's observability tools for improved monitoring
+    and logging.
+-   **DevOps-friendly management and development:** Manage your caching solution
+    using [Aiven Console](https://console.aiven.io/),
+    [Aiven CLI](https://github.com/aiven/aiven-client), or
+    [Terraform](/docs/tools/terraform) .
+    Features like scaling, forking, and upgrading your Aiven for Caching cluster
+    are simple and efficient. Compatible with open-source software, it integrates
+    with your existing applications and facilitates cloud and regional migrations.
+-   **Backups and disaster recovery:** Automatic and configurable backups ensure data
+    safety. Backups are performed every 24 hours, with retention periods varying by
+    service plan.
+
+## Ways to use Aiven for Caching
+
+- Use Aiven for Caching and its in-memory data store technology as a supplementary
+  data system alongside primary databases like PostgreSQL®.
+- Ideal for transient data, caching values for quick access, and data that can be
+  reestablished, such as session data. While this service is not inherently a
+  persistent storage solution, it can be configured for persistence.
+
+## Related pages
+
+- [Redis documentation](https://redis.io/documentation)
+- [Redis refcard on DZone](https://dzone.com/refcardz/getting-started-with-redis)