Redis for Administration is a course in running and managing Redis 8, the in-memory database, from data types and caching to persistence, security, replication, Sentinel and Redis Cluster, with monitoring through Prometheus and Grafana. It suits database administrators, DevOps engineers and developers who already have basic database knowledge.
Redis is the in-memory database behind a great many systems, handling caching, sessions, job queues, real-time counters and leaderboards. Because it keeps data in RAM it responds extremely fast, but once it reaches production, operations teams often run into memory filling up, data lost after a restart, a failed primary bringing the whole service down, or an instance left open without a password, even though Redis already has the tools to deal with all of this.
This course takes learners through using and managing Redis 8 from the basics to production readiness. It starts with installing Redis on Docker, working with redis-cli and Redis Insight, and understanding the core data types along with those now built into Redis 8, such as JSON and Time Series, before setting Redis up as a cache with a suitable eviction policy. It then goes deep into administration with Streams, transactions, Redis Functions, RDB and AOF persistence, ACL and TLS, and memory management, and moves on to replication, Sentinel, Redis Cluster and monitoring with Prometheus and Grafana. It closes with designing a fault-tolerant Redis deployment. (3 days, 6 hours per day, 18 hours in total, Beginner-Intermediate level.)
What you’ll gain
Install and configure Redis 8 with Docker and work fluently with redis-cli and Redis Insight
Choose the right data type for each job and manage keys and TTLs safely
Set Redis up as a cache with a suitable maxmemory and eviction policy
Use Streams, transactions, pipelining and Redis Functions at the right time
Configure RDB and AOF persistence, with backup and restore
Protect the system with ACL, TLS and secure network settings
Build high availability with replication, Sentinel and Redis Cluster
Monitor and troubleshoot performance with INFO, SLOWLOG, Prometheus and Grafana
Who this course is for
Database administrators responsible for Redis in their organisation's systems
System administrators and DevOps engineers who install and run Redis on servers or containers
Backend developers who use Redis for caching or queues and want to understand how it works underneath
People new to Redis who want the right foundations from the start
Anyone starting a career in databases and infrastructure
Prerequisites
Basic database knowledge, such as how data is stored and retrieved
Basic Linux command-line skills, such as managing files and reading logs
Docker experience is helpful, but no previous Redis experience is needed
A laptop that can run Docker Desktop, with permission to install software
Curriculum
Course Details
This is the 2026 edition of the Redis for Administration course, rewritten from scratch for Redis 8 with a stronger focus on real operations work. It runs for 3 days, 6 hours per day (18 hours in total, 09:00-16:00), as lectures with labs built on a single sample online store dataset throughout. Beginner-Intermediate level. Every lab runs on the learner's own machine with Docker, using only open source or free tools. Compared with the previous edition it adds the new Redis 8 data types, Redis Functions, eviction policies, ACL, TLS, Sentinel, Redis Cluster and monitoring with Prometheus and Grafana. Learners take home a lab guide, configuration files and scripts for every lab, and docker-compose files for replication, Sentinel, Cluster and monitoring.
Day 1Redis 8 Foundations and Caching
Section 1: Lab: Getting Started with Redis 8 on Docker
What Redis is, what it is used for and how it differs from SQL databases
Redis Open Source 8 and its licensing, and an overview of Valkey
Install Redis 8 with Docker Compose and the structure of redis.conf
Use redis-cli and Redis Insight to browse data and run commands
Basic settings: bind, port, protected-mode and databases
Section 2: Keys, TTLs and Strings
Naming keys systematically, and why KEYS should not be used in production
Browse keys safely with SCAN and TYPE
EXPIRE, TTL and PERSIST for data with a lifetime
Strings: SET with NX and EX, INCR and counters
Lab: a page-view counter and sessions that expire by themselves
Section 3: Lab: Hashes, Lists, Sets and Sorted Sets
Hashes for object-like data, and per-field expiry with HEXPIRE
Lists for job queues, and blocking commands such as BLMOVE
Sets for unique values, with unions and intersections
Sorted sets for leaderboards and time-ordered data
Lab: a shopping cart, a job queue and a leaderboard for the sample store
Section 4: Data Types Built into Redis 8
JSON for storing documents and updating parts of them directly
Time series for sensor data and metrics
Bitmaps, HyperLogLog and Bloom filters for memory-efficient counting and membership checks
An overview of the Query Engine and vector sets for search and AI workloads
Criteria for choosing a data type that fits the job and the memory budget
Section 5: Lab: Using Redis as a Cache the Right Way
Cache-aside and write-through patterns, and choosing TTLs
Set maxmemory and choose an eviction policy such as allkeys-lru or allkeys-lrm
The cache stampede problem and how to prevent it
Rate limiting with counters and time windows
Lab: put a cache in front of a sample database and measure it with redis-benchmark
Day 2Administration, Security and Persistence
Section 6: Lab: Pub/Sub and Streams
Pub/Sub for real-time notifications, and its limits around lost messages
Streams with XADD, XREAD and consumer groups
Handle pending messages with XPENDING, XCLAIM and XACK
Prevent duplicates with idempotent XADD in Redis 8.6 and later
Lab: an order queue processed by several consumers
Section 7: Transactions, Pipelining and Redis Functions
MULTI, EXEC and WATCH, and why Redis does not roll back
Pipelining to cut round trips to the server
Lua scripts with EVAL and EVALSHA
Redis Functions with FUNCTION LOAD and FCALL for logic that must be managed properly
Lab: atomic stock deduction without race conditions
Section 8: Lab: Persistence and Backup
RDB snapshots: save settings and BGSAVE
Multi-part AOF and choosing appendfsync
Combining RDB with AOF, and choosing what fits the workload
Backing up, moving to a new server and restoring from files
Lab: simulate a server crash and recover the data
Section 9: Lab: Security with ACL and TLS
Close the basic gaps: bind, protected-mode and firewalls
Create users with ACL SETUSER and limit them by command category and key pattern
Use ACL instead of rename-command and keep users in an ACL file
Enable TLS between clients and server and between replicas
Lab: separate users for the application, administrators and monitoring
Section 10: Memory Management
Read INFO memory and measure key sizes with MEMORY USAGE
Find big keys with redis-cli --bigkeys and hot keys with HOTKEYS
Fragmentation, active defrag and lazy free
Tune data encodings to reduce memory use
Lab: track down the cause of abnormal memory growth in sample data
Day 3High Availability, Scaling and Monitoring
Section 11: Lab: Replication
How primaries and replicas work, and configuring replicaof
Full sync, partial sync and the replication backlog
Sending reads to replicas, and the caveats of replication lag
Lab: set up one primary with two replicas and test synchronisation
Section 12: Lab: Redis Sentinel
What Sentinel does: monitoring, notification and automatic failover
Quorum, and why you need at least three Sentinels
Configure Sentinel to work with Redis ACL
Have applications connect through Sentinel to find the current primary
Lab: shut down the primary and watch a real failover
Section 13: Lab: Redis Cluster
The 16,384 hash slots and how data is spread across machines
Create a cluster with redis-cli --cluster
Hash tags for multi-key commands
Add or remove nodes and move slots with resharding
Lab: a six-node cluster with failover testing inside the cluster
Section 14: Monitoring and Troubleshooting
INFO, SLOWLOG, LATENCY and CLIENT LIST for finding root causes
Monitoring with Redis Exporter, Prometheus and Grafana
Key metrics: hit ratio, memory, connections and replication lag
Common problems: slow commands, exhausted connections and long forks
Design a system for a given scenario: choose Sentinel or Cluster and plan persistence
Deploy it with ACL, TLS, backup and monitoring in place
Upgrading from Redis 6 or 7 to Redis 8
An overview of Redis on Kubernetes and managed cloud services
Present the work, review it together and wrap up with a go-live checklist
Schedule & training options
For individuals — public rounds
No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770
What is Redis and how is it different from an SQL database?
Redis is an in-memory database that stores data as key-value pairs in RAM, which makes reads and writes very fast. It is widely used for caching, sessions, job queues and real-time counters. Unlike SQL databases, which store tables on disk and support complex queries, Redis has no joins, although it can persist data with RDB or AOF, and Redis 8 includes JSON, time series and a query engine. In practice it usually sits alongside a main database.
What are the main Redis data types and what are they used for?
Strings hold single values, such as text or numbers that can be incremented with INCR, ideal for caching and counters. Hashes hold several fields under one key for object-like data. Lists keep ordered items and work well as queues. Sets store unique values, sorted sets add a score for leaderboards, and streams hold event logs for queues with several consumers. Redis 8 also ships with JSON and time series out of the box.
Should I choose RDB or AOF to persist Redis data to disk?
RDB takes periodic snapshots of the whole dataset, giving small files and fast restores, but you can lose writes made after the last snapshot. AOF logs every write, so you lose far less depending on the appendfsync setting. For important data, use both together. For a pure cache, RDB alone or no persistence can be fine. Either way, test restores regularly.
Who is the Redis for Administration course for, and what should I know beforehand?
It suits database administrators, system administrators and DevOps engineers who look after Redis, backend developers who use Redis for caching or queues, and people new to Redis. You should have basic database knowledge and basic Linux command-line skills. Docker experience helps, but you do not need to have used Redis before.
What will I be able to do after the Redis for Administration course?
You will be able to install and configure Redis 8, choose the right data types, run Redis as a cache with an eviction policy, use Streams, transactions and Redis Functions, configure RDB and AOF with backup and restore, secure the system with ACL and TLS, build replication, Sentinel and Redis Cluster, and monitor it with Prometheus and Grafana. Participants who complete the training receive a Certificate of Completion with its own number, which can be verified online.
Can the Redis for Administration course be run in-house for our team?
Yes. It can be run in-house for your team, with examples adapted to your own work, such as the way your systems use Redis for caching or job queues. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.
GitOps is a way of doing continuous delivery that treats Git as the single source of truth for a system. Every change to applications and infrastructure happens through commits and pull requests that can be audited later, while a controller inside the cluster…
Blazor lets C# developers build interactive web pages using the same language on the front end and the back end, and Blazor WebAssembly runs .NET code directly in the browser. Paired with MongoDB, which stores flexible documents, it makes web applications…
Go, or Golang, is a language developed at Google that has become popular for backend, cloud and DevOps tooling. It compiles to a single file that runs anywhere you copy it, performs well, uses little memory and handles large amounts of concurrent work through…