MaiCoin case examine: Blue/inexperienced improve from Amazon ElastiCache Redis to Valkey

It is a visitor put up by Charles Hsiao, Web site reliability engineer (SRE) at MaiCoin, in partnership with AWS.

MaiCoin is a number one cryptocurrency trade and brokerage platform in Taiwan. It helps main property reminiscent of Bitcoin (BTC), Ethereum (ETH), Litecoin (LTC), Tether (USDT), and USD Coin (USDC), amongst others. The MaiCoin platform beforehand ran on a set of Amazon ElastiCache deployment clusters on Redis OSS.

Valkey is an open supply, excessive efficiency, key-value datastore stewarded by Linux Basis backed by greater than 40 corporations. Valkey is a drop-in alternative of Redis OSS, developed by long-standing Redis OSS contributors and maintainers, and has seen fast adoption since mission inception in March 2024. Amazon Internet Companies (AWS) is actively contributing to the Valkey mission. With rising market curiosity in Valkey, organizations together with MaiCoin are searching for dependable migration methodologies and finest practices.

Amazon ElastiCache for Valkey gives a totally managed service that simplifies this transition, providing automated failover, built-in safety, and seamless AWS integration. On this put up, we deep dive into MaiCoin’s enterprise use circumstances and their self-managed blue/inexperienced deployment methods that enable migration from Amazon ElastiCache for Redis to ElastiCache for Valkey with minimal downtime. The methods present the advantages of the absolutely managed capabilities of ElastiCache at a 20–33% decrease price.

Overview of present ElastiCache for Valkey managed migration technique

Amazon ElastiCache at present gives a managed in-place improve from Redis OSS to Valkey. On this improve method, a brand new set of Valkey nodes will get created in the identical cluster, which then replicate information from the present main nodes operating on Redis OSS. After the info replication course of is full, the service performs a failover, which promotes the brand new Valkey duplicate into main, updates the DNS endpoint of the ElastiCache cluster to level to the brand new Valkey nodes, and deletes the previous Redis OSS nodes from the cluster.

You should use this technique to improve the engine from Redis OSS to Valkey without having to handle the improve course of from the applying aspect. As a part of this improve, your utility connections will robotically get redirected to the brand new nodes operating Valkey.

MaiCoin case examine: The actual-world challenges of Valkey migration within the crypto trade

In crypto buying and selling and funds, millisecond-level latency and steady availability aren’t elective—they’re existential. As MaiCoin transitioned core caching workloads from Amazon ElastiCache for Redis OSS to ElastiCache for Valkey, we confronted challenges rooted in market dynamics and reliability expectations in a distributed system. The next part summarizes our key enterprise constraints, technical trade-offs, validation method, and enterprise outcomes.

MaiCoin confronted a number of enterprise constraints in migrating from ElastiCache for Redis OSS to ElastiCache for Valkey. As talked about above, migration is tougher in crypto on account of its demand for availability and millisecond latency. Further constraints embrace:

• Round-the-clock market nature of crypto buying and selling – Not like conventional inventory markets that shut each day or on weekends, the crypto market operates repeatedly. Even with scheduled upkeep home windows, migrations should account for stay buying and selling exercise to keep away from disrupting person belief.
• Tight latency budgets – P95 and P99 latency targets measured in low single digit milliseconds depart minimal room for added latency on account of TLS connection handshake, slot rebalancing, or cross-AZ site visitors routing.
• Burst tolerance – Market volatility can set off sudden surges in throughput and publish-subscribe (pub-sub) fan-out. The cache layer should stay steady not solely underneath common load but in addition underneath peak load.
• Regulatory and audit readiness – Sturdy traceability of configuration adjustments, reproducible infrastructure, and clear information retention are required to satisfy inner governance and regulatory requirements.

MaiCoin evaluated two migration methods, service in-place improve and self-managed blue/inexperienced deployment, every with distinct trade-offs.

The service in-place improve supplied simplicity: a single cluster endpoint, minimal utility adjustments, and a fast cutover. Nonetheless, it offered no stay validation window and lacked the power to roll again, which elevated restoration complexity.

In distinction, the blue/inexperienced deployment technique launched increased operational overhead and would quickly double the price of operation. Nevertheless it offered clear benefits in management, security, and observability. It enabled remoted validation, progressive site visitors shifting, and a dependable rollback path if anomalies occurred after cutover.

Given the important nature of buying and selling and pockets workloads to remain accessible across the clock with tight latency budgets and being compliant with regulatory audits, we selected blue/inexperienced deployment. This method meant we retained full management of the migration course of, decreased operational threat, and will guarantee a transparent rollback path aligned with our reliability requirements.

To validate Valkey’s readiness, we ran complete benchmarks evaluating Redis 7.1.0, Valkey 7.2.6, and Valkey 8.0.1. We used redis-benchmark for command-level latency and throughput, and memtier_benchmark for sustained, mixed-workload concurrency testing. We measured latency (common, p50, p95, and p99), throughput (TPS), and reminiscence effectivity (RSS, used reminiscence, and fragmentation ratio). Take a look at situations included GET/SET with 8-, 128-, and 2048-byte gadgets, record operations (LPUSH and LPOP), set operations (SADD and SPOP), sorted units (ZADD and ZPOPMIN), pipelining (-P 16), a 10-minute combined learn/write load, and a reminiscence effectivity take a look at with 1 million keys.

Throughout workloads, Valkey 8.0.1 achieved the best throughput, lowest latency (p50–p99), and finest reminiscence effectivity, with Valkey 7.2.6 shut behind. Below pipelining, Valkey led on SET throughput; in sustained load checks, Redis sometimes hit barely increased peak TPS however with worse p99 latency. General, Valkey 8.0.1 offered probably the most steady tail latency and lowest reminiscence fragmentation, indicating manufacturing readiness.

For information synchronization, we used RedisShake with a full sync (SCAN) adopted by steady updates by way of KSN.

We set rdb_restore_command_behavior=rewrite to forestall key conflicts; time to stay lengths (TTLs) have been preserved, and operating each modes allowed easy resynchronizations after interruptions.

Answer overview for blue/inexperienced migration from ElastiCache Redis to ElastiCache Valkey

Blue/inexperienced deployment is a method that reduces downtime and threat throughout migrations by sustaining two similar environments known as blue and inexperienced. On this migration state of affairs, blue represents the present ElastiCache Redis cluster, and inexperienced represents the goal ElastiCache Valkey cluster. At any time, just one setting actively serves manufacturing site visitors, with the opposite serving as a staging setting for information synchronization and validation. This method permits for a transition from ElastiCache for Redis OSS to ElastiCache for Valkey whereas sustaining information consistency and minimal service disruption.

RedisShake is an open supply device with Valkey help that’s developed by tair-opensource at Alibaba Cloud. It helps you progress information between Redis and Valkey clusters and gives a number of essential capabilities: it synchronizes information in real-time, works throughout completely different AWS areas, helps varied Redis and Valkey deployment varieties, and runs with minimal affect in your supply cluster’s efficiency.

RedisShake helps blue/inexperienced deployments by way of its synchronization engine. The device retains your information constant between your supply ElastiCache for Redis cluster (blue setting) and your goal ElastiCache for Valkey cluster (inexperienced setting). It copies information incrementally and maintains steady synchronization, so you may swap site visitors between environments easily if you’re prepared.

We used the next key migration modes:

• PSYNC mode – Implements Redis’s built-in partial synchronization protocol, establishing replication connections for stay manufacturing migrations with steady information synchronization
• RDB mode – Processes Redis Database (RDB) snapshot information with compressed binary representations, splendid for scheduled bulk migrations throughout upkeep home windows
• SCAN mode – Makes use of Redis SCAN instructions to traverse keyspace with out blocking, excellent for low-impact manufacturing migrations with managed useful resource consumption

Stipulations

Earlier than you carry out this migration, it is advisable:

• Provision supply cluster source-elasticache and goal cluster target-elasticache in your AWS account with the identical configuration, reminiscent of digital personal cloud (VPC) and occasion varieties, aside from the engine sort or model.
• Arrange a migration Amazon Elastic Compute Cloud (Amazon EC2) occasion in the identical VPC that enables connection entry to each the supply cluster and goal cluster.
• Request the Amazon ElastiCache service staff to allowPSYNCon each supply and goal clusters.

Answer walkthrough

To carry out the migration, full the next steps:

1. Obtain and set up RedisShake on the migration EC2 occasion:

   wget 
   tar -xzf redis-shake-linux-amd64.tar.gz
   ls -la redis-shake

2. Configuration setup utilizing the next configuration file (shake.toml):

   [sync_reader]
   cluster = false
   deal with = ":6379"
   username = ""
   password = ""
   tls = true
   sync_rdb = true
   sync_aof = true
   
   [redis_writer]
   cluster = false
   deal with = ":6379"
   username = ""
   password = ""
   tls = true
   
   [advanced]
   dir = "information"
   ncpu = 4
   
   [log]
   file = "redis-shake.log"
   stage = "information"
   keep_days = 7
   

   Configuration parameters:

   • sync_reader: Supply ElastiCache Redis cluster configuration
   • redis_writer: Goal ElastiCache Valkey cluster configuration
   • tls: Set to true for AWS ElastiCache connections (required)
   • sync_rdb and sync_aof: Allow snapshot and real-time synchronization
   • cluster: Set to true if utilizing cluster mode enabled
3. Arrange and execute the migration:

   mkdir -p information
   redis-cli -h  -p 6379 ping
   ./redis-shake shake.toml

4. Monitor the progress:

   tail -f redis-shake.log
   grep -i "sync" redis-shake.log | tail -10
   

5. Confirm the migration utilizing a verification script:

   #!/bin/bash
   echo "=== Migration Verification ==="
   LOCAL_KEYS=$(redis-cli -h  -p 6379 --tls DBSIZE)
   echo "Supply Redis Keys: $LOCAL_KEYS"
   
   echo "Pattern Knowledge Verification:"
   redis-cli -h  -p 6379 --tls GET person:1001:identify
   redis-cli -h  -p 6379 --tls HGET product:2001 identify
   
   echo "Goal Verification:"
   redis-cli -h  -p 6379 --tls DBSIZE
   redis-cli -h  -p 6379 --tls GET person:1001:identify
   
   if [ -f "redis-shake.log" ]; then
     echo "Migration Standing:"
     tail -3 redis-shake.log
   fi

Alternate options thought-about

Redis Enter/Output Instruments (RIOT) is one other open supply device for transferring information between Redis situations. Developed by Redis Ltd, this Java-based command line device helps you migrate and synchronize information throughout completely different Redis environments. RIOT gives a number of key options: it could possibly copy information in real-time, works throughout completely different cloud suppliers, helps various kinds of Redis setups, and has minimal affect in your supply Redis cluster throughout the migration runs. RIOT will help with blue/inexperienced deployments by repeatedly copying information from the supply ElastiCache for Redis OSS cluster (blue setting) to the goal ElastiCache for Valkey cluster (inexperienced setting). This ongoing synchronization means you may swap site visitors between environments easily.

RIOT grew to become unmaintained as of October 2025, and in consequence it wasn’t chosen as the answer for this migration state of affairs.

Enterprise consequence (why this issues)

MaiCoin achieved the next enterprise enhancements:

• Value effectivity – Valkey delivers significant financial savings in comparison with Redis OSS—roughly 20% decrease for ElastiCache self-designed cache clusters and as much as 33% decrease for ElastiCache Serverless. Mixed with AWS Graviton primarily based occasion varieties, it reduces annual run-rate with out sacrificing efficiency.
• Operational security – The blue/inexperienced technique, mixed with structured consistency checks, gives a repeatable and auditable migration framework for future upgrades.
• Efficiency headroom – Decrease tail latency and improved reminiscence utilization strengthen system resilience throughout market volatility.
• Future-proofing – With a confirmed rollback path and code-driven infrastructure provisioning, cluster growth and model upgrades turn into predictable and low-risk operations.

Conclusion

This put up explored MaiCoin’s sensible approaches utilizing RedisShake for migrating from Amazon ElastiCache for Redis OSS to Amazon ElastiCache for Valkey utilizing blue/inexperienced deployment methods. RedisShake gives a dependable migration path with steady information synchronization, so you may validate your goal setting earlier than switching manufacturing site visitors. It excels at large-scale migrations with detailed logging capabilities whereas sustaining near-zero downtime throughout the migration course of.

The important thing to profitable migration is correct planning: arrange community entry between clusters, allow TLS on each endpoints, monitor replication lag, and validate totally earlier than switching site visitors.

To get began, assess your present setting and your dataset dimension, then take a look at the method in a nonproduction setting first. The continual synchronization functionality of RedisShake provides you confidence to validate totally earlier than switching manufacturing site visitors.

In regards to the Authors