Private corporate batches, live online cohorts and 1-on-1 mentoring in distributed transactional key-value storage — multi-Raft regions, Percolator transactions and PD scheduling — 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 TiKV from the data path rather than the feature list — how a write travels from client to region leader through Raft to RocksDB, how region split, merge and leader transfer actually behave, and what an application observes while any of that is happening. Sessions go into the parts that decide whether a cluster is operable: MVCC and Percolator two-phase commit with lock resolution and GC safepoints, optimistic against pessimistic transactions, LSM compaction and write stalls read from real metrics, and PD scheduling driven live with pd-ctl — balance schedulers, store limits, hot region handling and location-aware placement rules. Failure work is hands-on, including replica loss, leaderless regions and unsafe recovery on a cluster deliberately broken in the lab.
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 TiKV that means a trainer who has run it in production — distributed transactional key-value storage — multi-Raft regions, Percolator transactions and PD scheduling — 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 TiKV batchTiKV is a distributed transactional key-value database written in Rust and graduated from the CNCF. It stores an ordered key space, splits that space into ranges called regions — roughly 96 MiB each by default — and replicates every region as its own Raft group, typically three replicas spread across separate stores. Because each region is an independent Raft group, the cluster scales by adding stores and splitting regions rather than by resharding, and the loss of a node costs a leader election per affected region rather than an outage.
Above replication sits a full transaction layer. TiKV implements the Percolator model: a two-phase commit coordinated through a lock column family, with timestamps issued by the Placement Driver acting as a global clock, MVCC versions keyed by commit timestamp, and background garbage collection behind a safepoint. Both optimistic and pessimistic transactions are supported, along with async commit and one-phase commit paths that cut latency for the common case. Applications reach the cluster through two APIs — RawKV for simple point and range operations with TTL and compare-and-swap, and TxnKV for full snapshot-isolation transactions — with clients in Rust, Go, Java and Python.
The Placement Driver is the other half of the system. PD holds cluster metadata, issues timestamps, and continuously schedules the cluster: balancing leaders and regions across stores, moving hot regions away from saturated nodes, honouring store limits, and applying placement rules and location labels so replicas respect rack and zone boundaries. Underneath everything, data lands in RocksDB with separate column families for data, write, lock and raft, which is why LSM behaviour — compaction, write stalls, block cache — shows up directly in TiKV performance work. Most TiKV in production sits beneath TiDB as its storage layer; standalone use through RawKV and TxnKV is a smaller but real niche.
The workloads that outgrow a single relational instance keep arriving, and the options are all expensive in different ways: shard the application by hand, buy a proprietary distributed database, or run an open-source one. TiKV is one of the few genuinely open, CNCF-graduated options that offers distributed ACID transactions rather than eventual consistency, which puts it in scope wherever correctness rules out a Dynamo-style store.
The more common route into TiKV is TiDB. Teams adopt TiDB for MySQL-compatible horizontal scale, then discover that every serious operational question — why writes stalled, why one store is hot, why a region has no leader, how to recover after losing two replicas — is a TiKV and PD question. Being able to read region state, interpret RocksDB metrics and drive pd-ctl is the difference between operating that cluster and hoping.
It is also one of the best available systems for learning distributed storage properly. Multi-Raft, MVCC over an LSM engine, Percolator two-phase commit and a live scheduler are all present, documented and observable in one codebase — so the knowledge transfers to etcd, CockroachDB, Spanner-style systems and beyond, not just to TiKV itself.
What problem TiKV solves and which problems it does not. Distributed key-value stores compared honestly — TiKV against etcd, Cassandra, DynamoDB and CockroachDB — the difference between standalone TiKV and TiKV as TiDB's storage layer, and the consistency guarantees that follow from the design.
Topics: Distributed key-value stores and their design trade-offs · TiKV compared with etcd, Cassandra, DynamoDB and CockroachDB · Standalone TiKV versus TiKV beneath TiDB · Consistency model, snapshot isolation and what is guaranteed · The component map: stores, PD, clients, and optionally TiDB · Deploying a first cluster with TiUP · When TiKV is the wrong choice
Following a single operation all the way down. Key space to region, region to Raft group, Raft group to leader, leader to RocksDB — and back. Region metadata, the store view, PD's role as metadata holder and timestamp oracle, and how a client locates the right leader.
Topics: The ordered key space and region ranges · Region metadata, epochs and version · How a client resolves a key to a region leader · Region cache in the client and stale-region handling · The write path: propose, replicate, apply, respond · The read path, leader reads and follower read options · PD as metadata store and timestamp oracle · Store heartbeats and region heartbeats
Consensus as it actually behaves under operations. Leader election and its timing, log replication and apply lag, snapshots when a follower falls too far behind, configuration change for adding and removing replicas, and the region split and merge machinery that keeps range sizes sane.
Topics: Raft roles, terms and leader election timing · Log replication, commit index and apply lag · Snapshots: generation, transfer and their cost · Joint consensus and safe membership change · Region split: triggers, thresholds and the split process · Region merge and empty-region cleanup · Leader transfer and evict-leader · Observing Raft health: down peers, pending peers, extra peers · What a client experiences during an election
Where most TiKV performance problems really live. LSM structure and why writes are cheap until compaction is not, the column families TiKV uses and what each holds, write stalls and their causes, block cache sizing, and the newer engine options that change the picture.
Topics: LSM trees: memtable, SST files, levels and compaction · TiKV column families: default, write, lock and raft · Compaction types, read and write amplification · Write stalls and flow control · Block cache, bloom filters and read performance · Raft Engine as a separate log store · Titan blob storage for large values · Partitioned Raft KV and where it helps · Reading RocksDB metrics from the TiKV Grafana dashboards
The layer that makes TiKV a database rather than a replicated map. Timestamp allocation, the Percolator two-phase commit protocol, primary and secondary locks, how a crashed coordinator's locks get resolved, snapshot isolation semantics, and the GC that stops MVCC versions accumulating forever.
Topics: Timestamp oracle, start_ts and commit_ts · Percolator two-phase commit: prewrite, commit, primary lock · The lock and write column families in practice · Optimistic transactions and conflict detection at commit · Pessimistic transactions and lock waiting · Lock resolution after a coordinator failure · Async commit and one-phase commit paths · Snapshot isolation and the anomalies it still permits · GC safepoint, resolve locks and the GC worker · Large transactions and their cost
Building against TiKV directly. RawKV versus TxnKV and the guarantees each gives up, the client libraries and their connection and retry behaviour, batching and scanning efficiently, and the key design work that determines whether load spreads or lands on one region.
Topics: RawKV: point operations, scans, TTL and compare-and-swap · TxnKV: snapshots, transactions and isolation · Go, Java, Rust and Python clients · Connection management, region cache and retry semantics · Batch operations and pipelining · Scan patterns and reverse scans · Key encoding and prefix design · Hotspot avoidance: sequential keys, shard prefixes, scattering · Coprocessor pushdown and what it can do
The cluster's brain. How PD decides what to move and when, the schedulers that balance leaders and regions, hot region handling, store limits that keep rebalancing from harming latency, and the labels and placement rules that keep replicas in different racks, zones or regions.
Topics: PD architecture, leader election and etcd-backed metadata · Balance-leader and balance-region schedulers · Hot region detection and hot-region scheduling · Store limits, scheduling speed and their effect on latency · Store labels and location awareness · Placement rules and rule groups · Evict-leader, transfer-peer and manual operators · Scheduling during rolling upgrades and node drains · Driving and inspecting all of it with pd-ctl
Everything required to run it after day one. Deployment with TiUP and with the operator on Kubernetes, the monitoring stack and the metrics that matter, backup and restore with BR, upgrades, capacity planning, and the recovery procedures for the failures that go past normal redundancy.
Topics: TiUP cluster deployment, scaling and rolling upgrade · TiDB Operator and TiKV on Kubernetes: StatefulSets, storage classes, PVs · Monitoring with Prometheus and the standard Grafana dashboards · The metrics that predict trouble: apply lag, pending peers, store size skew · Backup and restore with BR, and snapshot backups · Point-in-time recovery and change data capture · tikv-ctl and pd-ctl for inspection and repair · Losing majority replicas: unsafe recover and pd recover · Capacity planning: region count, store size, memory and disk · Security: TLS between components and client authentication
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy TiKV and PD with TiUP, load data until regions split, and observe region distribution, leader balance and store heartbeats as the cluster grows.
Drive sustained writes, kill region leaders, and measure election time, apply lag and the exact unavailability window a client experiences.
Push a write workload until compaction falls behind, identify the stall from RocksDB metrics, then tune the engine and prove the stall is gone.
Interrupt a two-phase commit, inspect the stranded primary and secondary locks with tikv-ctl, and watch lock resolution and GC clean up afterwards.
Add a store, watch PD rebalance regions, then use store limits and schedulers via pd-ctl to control the rate while keeping client latency inside a budget.
Destroy two of three replicas for a set of regions, restore service with unsafe recovery, then rebuild redundancy and verify data integrity against a BR backup.
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
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.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
| 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.