Private corporate batches, live online cohorts and 1-on-1 mentoring in Redis operations — persistence, memory and eviction, Sentinel and Cluster, latency troubleshooting — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Redis as a latency-critical operational system: why a single-threaded command loop makes one slow command everyone's problem, what an RDB fork really costs on a large instance, how maxmemory-policy decides whether Redis is a cache or a datastore, and the difference between Sentinel failover and Cluster resharding from the client's point of view. Sessions run against live instances — a stall reproduced with a big-key scan, a failover watched with clients connected, a resharding performed while traffic continues, and the slow log and latency tooling used to find the real cause rather than guess at it.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Redis that means a trainer who has run it in production — Redis operations — persistence, memory and eviction, Sentinel and Cluster, latency troubleshooting — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Redis batchRedis is an in-memory data structure store used as a cache, a database and a message broker. Rather than tables or documents, it exposes typed structures directly — strings, hashes, lists, sets, sorted sets, bitmaps, HyperLogLogs and streams — and operates on them with commands that are individually atomic. The core command execution path is single-threaded, which is why Redis is both extremely predictable and extremely unforgiving: one slow command blocks every other client on that instance.
Because the working set lives in memory, the operational questions are different from those of a disk-based database. How much memory the dataset really occupies, which maxmemory-policy governs eviction, whether persistence uses RDB snapshots, the append-only file, or both, and what each choice actually costs at fork time on a large instance — these decisions determine whether Redis is a cache you can lose or a datastore you cannot. Durability in Redis is a spectrum you configure, not a guarantee you inherit.
Scaling and availability come from two separate mechanisms that are often confused. Replication plus Sentinel gives automatic failover for a single logical dataset; Redis Cluster shards the keyspace across 16,384 hash slots with its own client protocol, redirection behaviour and resharding process. Both change what clients must handle. Add ACLs, TLS, the slow log, latency monitoring and keyspace analysis, and the operational surface is substantial — and it stays substantial on ElastiCache, Memorystore or a Kubernetes operator, where the instances are managed but the eviction policy, key design and failover behaviour are still yours.
Redis has ended up in the critical path of far more systems than were designed for it. It starts as a cache, then holds sessions, then rate limits, then a job queue, then a lock — and at some point losing it means an outage rather than a slow page. Very few teams re-examine the configuration when that transition happens, which is why so many production incidents trace back to a Redis instance still running with the defaults it was installed with.
The failure modes are specific and teachable. A KEYS or a large SMEMBERS on the single-threaded command loop stalls every client. An instance with no maxmemory set grows until the kernel kills it. An RDB fork on a large instance doubles resident memory on a host with no headroom. Replication is asynchronous, so a Sentinel failover silently loses the last writes. A client library that does not understand MOVED and ASK redirection fails intermittently after a resharding. None of these produce a helpful error message; they produce latency and confusion.
The surrounding landscape has also shifted. Licence changes upstream produced the Valkey fork and a set of drop-in alternatives, so choosing what to run — and knowing how compatible the options are — has become part of the operator's job rather than a formality. Meanwhile every managed offering still leaves key design, eviction policy, memory headroom and failover semantics to the team that owns the service.
How Redis executes work and why that shapes everything else. The single-threaded command loop, the event model, and the I/O threading that exists in recent versions. Then the data structures themselves, viewed operationally: memory footprint, encoding thresholds, command time complexity, and which commands can block the server.
Topics: The single-threaded command loop and the event model · Strings, hashes, lists, sets and sorted sets · Streams, bitmaps and HyperLogLog · Internal encodings and the thresholds that change them · Command time complexity and blocking commands · Pipelining, transactions and Lua scripting · Keyspace design and naming conventions that scale
Deciding how much data you are willing to lose, and paying the price knowingly. RDB snapshots and the fork behaviour that surprises people on large instances, the append-only file with its fsync policies and rewrite cycle, running both together, and what recovery actually looks like from each.
Topics: RDB snapshots, save points and manual BGSAVE · Fork cost, copy-on-write and memory spikes · AOF: appendfsync policies and the durability trade-off · AOF rewrite and the multi-part AOF format · Running RDB and AOF together · Recovery and startup behaviour from each format · Backup, restore and off-host copies
The topic that decides whether Redis behaves as designed or gets killed by the kernel. Reading real memory usage, the maxmemory setting and every eviction policy, expiry and its lazy plus active cycles, fragmentation and defragmentation, big-key and hot-key analysis, and capacity planning that leaves room for a fork.
Topics: INFO memory and where the bytes actually go · maxmemory and each eviction policy in turn · Key expiry: lazy and active cycles · Memory fragmentation and active defragmentation · Finding big keys and hot keys safely · OOM behaviour and what the kernel does · Capacity planning with persistence headroom
Availability for a single logical dataset. How asynchronous replication works and where writes are lost, partial versus full resynchronisation, replica read behaviour and staleness, then Sentinel — quorum, monitoring, automatic failover, client discovery — and the failure modes Sentinel itself introduces.
Topics: Asynchronous replication and the replication backlog · Partial and full resynchronisation · Replica reads, staleness and read-only enforcement · WAIT and min-replicas settings · Sentinel architecture, quorum and monitoring · Automatic failover and client rediscovery · Split-brain scenarios and how to avoid them
Scaling the keyspace horizontally. The 16,384 hash slot model, slot assignment and hash tags, the cluster bus and gossip protocol, MOVED and ASK redirection and what the client library must implement, adding and removing nodes, live resharding, and the operational differences between Cluster and Sentinel.
Topics: Hash slots, slot assignment and hash tags · The cluster bus and gossip protocol · MOVED and ASK redirection and client requirements · Multi-key operations and their constraints · Adding and removing nodes · Resharding while serving traffic · Node failure, replica promotion and cluster-wide availability · Cluster versus Sentinel: choosing correctly
Redis is famously easy to expose by accident. Protected mode, network binding, ACL users and command restrictions, TLS, and command renaming or disabling. Then deployment: configuration management, containers, the Kubernetes operators, managed services such as ElastiCache and Memorystore, and how the Valkey fork and its alternatives compare.
Topics: Protected mode, bind addresses and network exposure · ACL users, categories and command restrictions · TLS for client and replication traffic · Renaming and disabling dangerous commands · Deploying with configuration management and containers · Redis on Kubernetes: operators and StatefulSets · Managed Redis: ElastiCache, Memorystore and their limits · Valkey and compatible alternatives
Finding the real cause of a latency problem while it is still happening. The slow log, the latency monitor, INFO commandstats and latencystats, client tracking and connection limits, safe use of SCAN, the effect of persistence and replication on latency, and the alerts a Redis estate actually needs.
Topics: Slow log configuration and interpretation · The latency monitor and intrinsic latency baseline · INFO commandstats, latencystats and keyspace stats · CLIENT LIST, connection limits and output buffer limits · SCAN and safe iteration over a live keyspace · Latency from persistence, replication and swap · Monitoring with exporters, Prometheus and Grafana · Benchmarking with redis-benchmark and memtier
We rebuild the agenda around the tools you actually run.
Request a custom agendaFill an instance past maxmemory under allkeys-lru, volatile-ttl and noeviction, and document exactly what each policy does to the application.
Trigger a background save on a large instance, measure the copy-on-write memory spike, then hard-kill the process and recover from AOF, reporting the exact data loss.
Run a write workload against a Sentinel-managed replica set, fail the primary, and measure the error window and the number of acknowledged writes that disappeared.
Build a six-node cluster, move hash slots between shards under continuous load, and observe MOVED and ASK redirection from the client side.
Reproduce a server-wide stall with a single O(N) command, then locate it using only the slow log, latency monitor and commandstats.
Deploy a secured, monitored, replicated Redis from configuration management, then take it through a failover, a resharding and a recovery drill with documented client impact.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.