[Chuseok Special] A Naver Developer Explains Valkey: Mastering 1M++ TPS!
When Redis alone can no longer guarantee performance, what options do we have?? There is Valkey, which is 100% compatible with Redis and applies IO-based tuning. Through this course, let’s explore how Valkey guarantees 1M++ TPS and learn about the data structures suited to different traffic patterns and feature implementations.
I've watched almost all of your lectures, and I'm amazed every time I watch them. I don't know how you manage to cover such a wide variety of topics with so much valuable content...
Thank you so much for always being such a great help. I was planning to binge-watch them over Chuseok, but once I started watching one before Chuseok, the content was so worthwhile that I've already watched them all;; hahaha
What you will gain after the course
E-commerce backend with caching, cart, ranking, inventory, and order pipelines (TypeScript mini project)
A caching strategy designed from cache-aside through invalidation, stampede protection, and TTL jitter
Concurrency handling capabilities that protect inventory management and sales using atomic operations, distributed locks, and Lua.
Criteria for choosing between List queues, Pub/Sub, and Stream consumer groups
Persistence design that selects RDB, AOF, and eviction policies according to the situation
Diagnostic capability to identify big keys and hot keys using SLOWLOG and bigkeys
Operational capability to configure automatic failover using replication and Sentinel
Horizontal scaling covering 6-node cluster setup, resharding, and hashtags
Performance tuning methods for locating bottlenecks through pipelining and I/O threading
Considerations When Moving from Redis to Valkey (Licensing, Compatibility, and Measured Differences)
VALKEY · IN-MEMORY DATABASE
Valkey vs Redis: Master 1 million TPS with a Naver developer
We recreate the scenes I’ve experienced over 10 years of building servers at Naver. Moments when inventory showed negative numbers and the database staggered as the cache expired all at once. You’ll build a small e-commerce service and learn continuously, from caching to replication, Sentinel, and cluster operations—and finally, personally surpass 1 million requests per second on a single laptop.
1,331,558 RPS
These are the actual requests per second measured on the instructor’s laptop (8-core Apple Silicon, Valkey 9.1), based on GET operations. The figure was obtained under conditions using a pipeline of 16 commands at a time, and it can drop to as low as 980,000 when the conditions change. We show those fluctuations exactly as they occur in the course as well. (The “1 million TPS” in the course title is a general term for throughput, while the actual measurement label is listed as RPS.)
I knew the commands, but operating them was a different story.
"I know SET and GET, but I don't know how to use them in practice."There are plenty of courses that simply list commands, but few cover the practical workflow connecting cache strategies, concurrency, and event pipelines.
"The inventory went negative, but I don't know why."You won't understand concurrency failures until you've experienced one. In this course, you'll deliberately trigger one, see it with your own eyes, and then learn how to prevent it.
"If the server goes down, the service just goes down with it."Replication, automatic failover, and sharding — build the operational infrastructure yourself with Docker, then deliberately take down the server and see what happens.
WHY VALKEY
Why Valkey Instead of Redis
IN-MEMORY DATABASE
Valkey
9.1 · BSD · Linux Foundation
Valkey is a fully open-source in-memory database created by the community by forking Redis shortly after Redis changed its license in 2024. It is supported by AWS, Google, and Oracle under the Linux Foundation. If you’re learning about in-memory databases from scratch today, starting with this fork in the road will help you understand things more quickly.
Valkey
Fully open source (retaining the BSD license)
Under the Linux Foundation · Development supported by AWS, Google, and Oracle
After the fork, focused investment in performance, including redesigning I/O threading
Offered at a lower price than the Redis engine on AWS ElastiCache
Redis
Switched to a commercial license in 2024, then partially reopened in 2025
Original project, extensive documentation ecosystem
Protocols and commands are compatible with Valkey
This course is conducted based on Valkey, but since its protocol is compatible, most of what you learn applies directly to Redis as well. For those coming from Redis, we’ll point out “what has changed in Valkey” throughout the course.
And one more thing — there still aren't many Korean-language resources that cover Valkey from the basics through production operations. If you learn it now, you'll gain knowledge that few others have.
MEASURED, NOT CLAIMED
All the numbers in this course are based on actual measurements.
I did not simply reproduce the manufacturer’s benchmarks. Every figure in this course was obtained by the instructor running the tests directly on the same laptop, and results that did not turn out well are shown as-is without being cut — because understanding why they didn’t turn out well is the more important lesson.
46 vs 0
Inventory that disappeared during a simultaneous purchase by 50 people (race condition) vs. the result prevented with an atomic operation
4.5 seconds → BUSY
A slow command bringing the entire server to a halt — seeing the single thread with your own eyes
15 seconds
After killing the master, until Sentinel automatically elects a new master
6.6x
The Throughput Gap Created by Pipelining Alone — The Secret Behind 1 Million
I also included the measurements from the opposite direction as they were. When I increased the number of I/O threads to six, GET actually became 12% slower on my laptop. At the end of the lecture, I dig into why that happened and what actually produced the 1 million.
WHAT ACTUALLY HAPPENS
The scenes where those numbers appeared
I’ve illustrated which screen each of the four numbers above came from. In the lecture, I recreate this directly in the terminal.
SECTION 1
Single-threaded — the next command runs only after the previous command finishes
EVAL
PING
BUSY
Valkey processes commands one at a time. While a heavy Lua script was running, a normally 7-millisecond PING had to wait 4.5 seconds. If the lock is held for more than 5 seconds, the server returns a BUSY error to subsequent clients.
SECTION 5
Race condition — another request intervenes between GET and SET
client A
GET → 50SET 49
client B
GET → 50SET 49
46
Remaining inventory using GET, calculation, and SET
0
If you replace it with a single DECRBY line
We processed 50 requests, but only 4 deductions were reflected. That’s because the two clients read the same value and wrote the same value. The fact that the result varies between 46 and 47 each time it runs is a characteristic of a race condition.
SECTION 9
Sentinel — Handles failure detection and promotion without human intervention
sentinel-1
sentinel-2
sentinel-3
master
Promote replica-2
If the response is interrupted for 5 seconds (down-after), each Sentinel marks it as subjectively down, and once a quorum of 2 is reached, it is confirmed as objectively down. After directly terminating the master process, a new master is promoted within 15 seconds.
SECTION 2 · 11
The bottleneck wasn’t server performance—it was the round trip.
One at a time
128,534
Batched in groups of 10
850,000
1,331,558
From a single laptop: GET benchmark · RPS · p50 0.975ms
Keeping the server and commands unchanged and batching only the round trips in groups of 10 resulted in a 6.6x improvement (128,534 → 850,000). At the end of the course, increasing the batch size to 16 and matching the conditions takes it up to 1.33 million.
PREVIEW
Rather than a hundred words of explanation, see it for yourself
This isn’t a theory slide—it’s an actual terminal screen. Here are four scenes covered directly in the lecture, cut down into short clips.
Set up a 6-node cluster.
This is the scene where the nodes are launched with Compose and assigned 16,384 hash slots using --cluster create.
We directly identify slow keys.
We use --bigkeys and SLOWLOG to track which keys consume memory and which commands hold up responses.
Verify that the data remains after turning it off and back on.
Create a snapshot with BGSAVE, enable appendonly, then restart and visually confirm that the data actually survives.
Prevent the inventory from going negative.
We upload a conditional deduction Lua script and execute it with EVALSHA to confirm that no overselling occurs even with concurrent orders.
We learn from these pieces of evidence by reproducing them ourselves.
The four scenes you just saw are reproduced exactly in the lecture.
HOW IT FLOWS
As a small e-commerce business grows, learn only what you need.
We don’t memorize data structures in order. We bring out the right tool whenever the service needs a new feature. By the end of the course, you’ll have a complete e-commerce backend, from caching to cluster operations.
The product page is slowAdd caching — String, TTL, cache-aside, and stampede protection
A customer adds a productCart and session — Hash, sliding expiration
Let's display the popularity rankingsFavorites and rankings — Set, ZSet, HyperLogLog, Bitmap
As orders flood in, inventory disappearsReproducing a concurrency incident — atomic operations, distributed locks, Lua
Post-order processing starts piling upEvent pipelines — List queues, Pub/Sub, and Stream consumer groups
Commands as codeTypeScript mini-project — 1:1 correspondence between the CLI and the code
It disappears when you turn it off and onPersistence and memory — RDB, AOF, eviction, and diagnostic tools
If a single server goes downReplication and Sentinel — observe automatic failover firsthand
When your data grows larger than a single serverCluster — hash slots, resharding, cluster failover
Final PromiseAfter seeing real-world measurements where enabling I/O threading actually made things slower, find the real bottleneck and surpass 1 million on a laptop
WHY NOW
Do you still know only Redis ?
This is how someone who has been building servers at Naver for 10 years sees it. It’s not that you don’t need to know Redis; the landscape has already shifted since the 2024 licensing controversy. The numbers make it even clearer.
1 billion RPS
Requests per second handled by Valkey 9 in a large-scale 2,000-node cluster. It delivers 2.1 million RPS on a single server.
15,000 servers
The number of servers Aiven migrated from Redis to Valkey in just three months. It is the largest publicly disclosed migration.
45%
Infrastructure costs Amazon Ads reduced by switching to Valkey. Throughput actually increased by 12%.
27,000
GitHub stars. More than 700 contributors are involved, with 1,300 forks.
9 million
Number of downloads of the official Docker image. Based on valkey/valkey.
AWS ElastiCache and Google Memorystore provide Valkey by default for new clusters. The default cache package in major Linux distributions is also Valkey. To use Redis, you now have to choose it separately.
But once you’ve migrated, operations still ultimately come down to people—setting up replication, verifying failover, and rebalancing the slots. This course covers that part.
Sources: Valkey 9.0·9.1 release notes · AWS Database Blog (Valkey turns two, Amazon Ads case study) · Aiven migration case study · valkey-io GitHub · Docker Hub valkey/valkey
WHAT YOU CAN CLAIM
Use it in your portfolio and resume as-is.
"I’ve used Redis" and "I reduced the overselling that occurred during 50 concurrent purchases to zero" are different sentences. To write the latter, you need to cause the problem yourself and measure it yourself, and this course takes you through that process. Once you complete the course, you can use the six lines below as-is.
Write it like this on your résumé
01Blocked sharp DB load spikes caused by cache stampedes using TTL jitter and NX-based preemptionReproduced overlapping invalidation timing and designed a defense strategy for simultaneous refreshes by two workers
02Reduced the inventory overselling that occurred during 50 concurrent purchases to 0 using atomic operations and LuaWe first reproduced the GET·SET race condition, confirmed the inventory discrepancy could reach 46, and then prevented it
03Implemented an owner-token-based distributed lock to prevent other processes from accidentally releasing the lockAcquired the lock with SET NX PX and released it atomically with unlock.lua, also addressing the possibility of double acquisition during expiration and failover
04Configured Sentinel-based automatic failover and verified promotion within 15 seconds when the master failedDirectly terminated the master process and observed the period when two masters were temporarily visible, along with demotion and catch-up
05Built a 6-node cluster and resolved CROSSSLOT errors through online resharding and hash tagsPersonally carried out everything from distributing 16,384 hash slots to zero-downtime slot migration and cluster failover
06Improved throughput by 6.6× with pipelining and identified round trips as the bottleneckWe also measured cases where increasing I/O threads actually made things 12% slower, leaving evidence of what the real bottleneck was
All six items are built and measured directly in this course. Even if an interviewer asks, "So how did you verify it?", you’ll have a clear answer.
When the course is over, you’ll have an e-commerce backend repository, which can serve as your portfolio as-is.
WHO & WHAT
This is a good fit for:
Backend developers and job seekers learning in-memory databases for the first time (no prior knowledge required)
Those who have only used Redis at the command level and want to expand their knowledge to caching strategies, concurrency, and operations
Those considering switching to Valkey following the Redis licensing issue
Those who have wanted to build replication, failover, and clusters themselves
Requirements: macOS (Apple Silicon recommended) + Homebrew. Docker Desktop is used only for the replication and cluster exercises in the latter part. Until then, one terminal is all you need. The hands-on exercises start with valkey-cli, continue with the TypeScript client iovalkey, and measure throughput directly with valkey-benchmark.
INSTRUCTOR
Instructor Introduction
Created together by Ande, a 10-year backend developer at NAVER headquarters, and Hong, a platform server developer in Pangyo.
NAVER · BACKEND ENGINEER · 10 years of experience
Ande
I’m a backend developer with 10 years of experience developing servers at NAVER’s headquarters. Incidents where inventory is recorded as negative, or situations where the database buckles as caches all expire at once—most of the scenes I recreate and demonstrate in the course are based on things I’ve actually experienced in the field. Feel free to leave your questions; I’ll look into them and answer them as thoroughly as possible.
I don’t show only the numbers that turned out well. We learn more from the numbers that didn’t.
Current Naver server developer (headquarters) · Former Shinsegae Group backend developer · Former healthcare startup server developer · Computer Engineering major at a four-year university in Seoul
Knowledge Sharer · Pangyo Platform Server Development
Hong
I work on platform server development in Pangyo. I continue my activities as a knowledge sharer to share the methods I used to study independently, along with the problems and solutions I encounter in practice. For this course, I designed the curriculum and handled the filming.
I had to start by explaining why someone who only knew Redis should take a look at Valkey. I incorporated that sequence into the course as is.
Current Pangyo Platform Server Developer · Former Blockchain & Metaverse Backend Developer · Inflearn Knowledge Sharer
Curriculum designNumerous backend coursesPlatform server
MESSAGES
So, will Hong really be helpful?
I've finished the entire course. Thank you for the excellent course.The message you left in the open chat room after completing the courseThanks to your course, I received a great deal of help and was able to get a job offerThe news of your job offer shared in the open chat room
Receiving messages like this is why I continue creating courses. I hope this course can become that kind of one line for someone as well.
FAQ
Frequently Asked Questions
What is Valkey? How is it related to Redis?
Valkey is a fully open-source (BSD) in-memory key-value database created by the community by forking Redis 7.2 after Redis changed its license in 2024. It operates under the Linux Foundation with support from AWS, Google, and Oracle, and is compatible with the Redis protocol. In the first video of the course, we’ll explain the story behind its creation.
The company still uses Redis, so does it still make sense?
Yes. Valkey and Redis are compatible at the protocol and command levels, so the cache strategies, concurrency handling, replication, Sentinel, and cluster operation knowledge covered in the course can be applied directly to Redis environments as well. Conversely, we also cover the licensing background and measured differences that can serve as a basis for decision-making if your company considers switching to Valkey.
How difficult is it? Do I need to go through everything from the beginning?
The first part is designed to follow without prior knowledge, while the latter part covers advanced operational topics such as persistence, replication, clustering, and performance. Since the course is structured around continuing to build an e-commerce service, I recommend watching it from the beginning, but if you have experience with Redis, you can pick and choose topics starting with concurrency or advanced operations. What each video covers is listed below in the curriculum.
Is it okay if I don't know Redis?
Yes. It is designed so you can start without any prior knowledge. Conversely, if you have experience with Redis, most of what you know carries over almost directly, and the points that differ in Valkey (improved defaults and new features) are highlighted separately throughout the course.
Can I do the hands-on exercises on Windows as well?
The course is conducted using macOS + Homebrew. Windows is not officially supported because the screens and installation process are different.
Can you really get 1 million TPS?
On the instructor’s laptop (8-core Apple Silicon), we measured 1,331,558 RPS for GET requests under a pipeline configuration that batches commands in groups of 16. We show the execution and commands exactly as they appear in the course. We also share measurements showing that, even under the same conditions, performance dropped to 980,000 RPS depending on the run, and that enabling I/O threads actually made it slower. For reference, “TPS” in the course title is a general term for throughput, while the measurement label on the page is listed as RPS based on GET requests.
Can I follow along even if I’m not good at coding?
Two-thirds of the course consists of hands-on terminal command exercises, so almost no coding experience is required. The TypeScript is concentrated in one place (the mini-project), and we go through it explaining every line of code.
Which version do you use?
It is based on Valkey 9.1. Every command and configuration in the course was executed and verified directly on this version.
Kill the server yourself, and push it past one million yourself.
This is not a lecture about memorizing commands; it is about solving, one by one, the problems that arise as a service grows. By the end of the course, you will have prevented inventory incidents with atomic operations, killed and revived the master yourself, and set up a six-node cluster.
COMMUNITY
You don’t have to study alone.
Share your sticking points during the course, career concerns, and real-world experiences in an open chat where developers gather. Questions about the course are welcome too.
Career and job changesBackend development in the fieldTechnical Q&AStudy groups
I started studying development after becoming interested in it while idling at home, and I am currently responsible for platform server development in Pangyo. I am continuing my activities as a knowledge sharer because I want to provide you with the methods I used to study, as well as the various problems and solutions you may encounter in practice.
These lectures are not created solely through my own knowledge. There are others who collaborate on every lecture.