Skip to content

add AZ_AFFINITY_REPLICAS_AND_PRIMARY read strategy example and diagram #236

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 26, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions content/authors/muhammadawawdi.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
---
title: Muhammad Awawdi
extra:
photo: '/assets/media/authors/muhammadawawdi.jpeg'
github: muhammad-awawdi-amazon
---

Muhammad is a software engineer at AWS ElastiCache, building Valkey GLIDE and large-scale distributed systems. When he’s not building faster tech, he’s lifting weights, grilling barbecue, or geeking out over the latest innovations.
24 changes: 21 additions & 3 deletions content/blog/2024-12-22-az-affinity-strategy.md
Original file line number Diff line number Diff line change
@@ -2,7 +2,7 @@
title= "Reducing application latency and lowering Cloud bill by setting up your client library"
date= 2025-01-08 01:01:01
description= "By implementing AZ affinity routing in Valkey and using GLIDE, you can achieve lower latency and cost savings by routing requests to replicas in the same AZ as the client."
authors= [ "asafporatstoler", "adarovadya"]
authors= [ "asafporatstoler", "adarovadya", "muhammadawawdi"]
+++
How can adjusting your client library help you reduce Cloud costs and improve latency?

@@ -28,8 +28,9 @@ GLIDE provides flexible options tailored to your application’s needs:
* ```PRIMARY```: Always read from the primary to ensure the freshness of data.
* ```PREFER_REPLICA```: Distribute requests among all replicas in a round-robin manner. If no replica is available, fallback to the primary.
* ```AZ_AFFINITY```: Prioritize replicas in the same AZ as the client. If no replicas are available in the zone, fallback to other replicas or the primary if needed.
* ```AZ_AFFINITY_REPLICAS_AND_PRIMARY```: Prioritize replicas in the same AZ as the client. If no replicas are available in the zone, fallback to the primary in the same AZ. If neither are available, fallback to other replicas or the primary in other zones.

In Valkey 8, ```availability-zone``` configuration was introduced, allowing clients to specify the AZ for each Valkey server. GLIDE leverages this new configuration to empower its users with the ability to use AZ Affinity routing. At the time of writing, GLIDE is the only Valkey client library supporting the AZ Affinity strategy, offering a unique advantage.
In Valkey 8, ```availability-zone``` configuration was introduced, allowing clients to specify the AZ for each Valkey server. GLIDE leverages this new configuration to empower its users with the ability to use AZ Affinity routing. At the time of writing, GLIDE is the only Valkey client library supporting the AZ Affinity strategies, offering a unique advantage.

## AZ Affinity routing advantages

@@ -40,7 +41,7 @@ In Valkey 8, ```availability-zone``` configuration was introduced, allowing cli

2. **Minimize Latency** Distance between AZs within the same region— for example, in AWS, is typically up to 60 miles (100 kilometers)—adds extra roundtrip latency, usually in the range of 500µs to 1000µs. By ensuring requests remain within the same AZ, you can reduce latency and improve the responsiveness of your application.

**Example:**
**Example 1:**
Consider a cluster with three nodes, one primary and two replicas. Each node is located in a different availability zone. The client located in az-2 along with replica-1.

**With ```PREFER_REPLICA``` strategy**:
@@ -53,6 +54,20 @@ In Valkey 8, ```availability-zone``` configuration was introduced, allowing cli
In this case, the client will read commands from a replica in the same client's AZ and the average latency is, for example, about 300 microseconds.

![AZ_AFFINITY Read strategy latency example](/assets/media/pictures/AZ_AFFINITY_strategy.png)

**Example 2:**
Consider a cluster with three nodes, one primary and two replicas. Each node is located in a different availability zone. The client located in az-2 along with the primary node. The replicas are located in az-1 and az-3.

**With ```AZ_AFFINITY``` strategy**:
In this case, the client attempts to read from a replica in the same AZ. Since none are available in az-2, it falls back to a replica in another AZ, such as az-1 or az-3.
and the average latency is, for example, about 800 microseconds.

![AZ_AFFINITY Read strategy latency example](/assets/media/pictures/AZ_AFFINITY_strategy2.png)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's confusing that in the first example the "super" client is the AZ_AFFINITY user, but later the "super" client becomes the AZ_AFFINITY_REPLICAS_AND_PRIMARY user.
I suggest having one example that clearly shows all three cases, and explaining when a user should prefer AZ_AFFINITY over AZ_AFFINITY_REPLICAS_AND_PRIMARY, and vice versa.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this a bit differently. The new example visually clarifies the differences between AZ_AFFINITY and AZ_AFFINITY_REPLICAS_AND_PRIMARY, illustrating real-world scenarios where each one fits best. I'd prefer to retain both examples.


**With `AZ_AFFINITY_REPLICAS_AND_PRIMARY` strategy**:
In this case, the client first attempts to read from a replica in the same AZ. Since no local replica exists, it reads from the primary located in az-2. The average latency is, for example, about 300 microseconds.

![AZ_AFFINITY_REPLICAS_AND_PRIMARY Read strategy latency example](/assets/media/pictures/AZ_AFFINITY_REPLICAS_AND_PRIMARY_strategy.png)

## Configuring AZ Affinity Connections with GLIDE

@@ -152,6 +167,9 @@ Setting up AZ affinity routing in GLIDE is simple, allowing you to leverage its
## Conclusion
By implementing AZ affinity routing in Valkey and using GLIDE, you can achieve lower latency and cost savings by routing requests to replicas in the same AZ as the client.

---
*Updated May 2025 to cover the `AZ_AFFINITY_REPLICAS_AND_PRIMARY` strategy and a corresponding example.*

### Further Reading
* [Valkey GLIDE GitHub Repository](https://github.com/valkey-io/valkey-glide)
* [Valkey Documentation](https://valkey.io/)
Binary file added static/assets/media/authors/muhammadawawdi.jpeg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.