Private corporate batches, live online cohorts and 1-on-1 mentoring in Kafka cluster administration — brokers and replication, KRaft, security, tuning and disaster recovery — 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 Kafka as cluster operations rather than as a client API: the partitioned log and page-cache behaviour that explain its throughput, the exact interaction of acks, in-sync replicas, min.insync.replicas and unclean leader election that decides whether a cluster loses data, the ZooKeeper-to-KRaft migration path, and consumer group lag as the signal everything else is judged against. Sessions run on multi-broker clusters — a broker killed while producers are writing, a partition reassignment executed under load, a rolling upgrade, and a durability setting proven wrong by measurement rather than argued about.
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 Kafka that means a trainer who has run it in production — Kafka cluster administration — brokers and replication, KRaft, security, tuning and disaster recovery — 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 Kafka batchApache Kafka is a distributed event streaming platform built around an append-only, partitioned commit log. A topic is split into partitions; each partition is an ordered, immutable sequence of records that brokers write sequentially to disk and serve from page cache. Consumers track their own position through offsets rather than the broker tracking delivery, which is why Kafka can replay history, feed many independent consumers from the same data, and sustain throughput that message queues built around per-message acknowledgement cannot.
Operationally, Kafka is a replicated distributed system with a specific set of levers. Each partition has a leader and followers, and the in-sync replica set combined with acks, min.insync.replicas and unclean leader election settings determines exactly what durability the cluster provides — and where it silently loses data if those settings disagree. Cluster metadata was historically kept in a ZooKeeper ensemble; modern Kafka uses KRaft, with the controller quorum inside Kafka itself, and most real estates are somewhere along that migration.
The rest of the operator's surface is broad: partition count and retention decisions that are hard to reverse, log compaction, partition reassignment and rebalancing, rolling restarts, consumer group lag as the primary health signal, TLS and SASL with ACLs and quotas, and OS-level tuning of I/O, page cache, network and file descriptors. Around the broker sit Kafka Connect, Schema Registry, Kafka Streams and the REST proxy — and managed offerings such as MSK and Confluent Cloud, which run the brokers but leave topic design, partitioning, retention and lag firmly with the team.
Kafka has become default infrastructure. It carries application events, database change streams, log and metric pipelines, and increasingly the data path for analytics and machine learning. That makes it one of the highest-blast-radius systems a platform team runs: when Kafka degrades, it does not fail one feature, it stalls everything downstream of it.
And it is routinely operated on assumptions. Topics are created with the default partition count and never revisited, so throughput hits a ceiling nobody can explain. Producers use acks=1 against a topic whose owners believe writes are durable. min.insync.replicas is left at 1, so a two-replica outage quietly accepts writes that are about to be lost. Unclean leader election is enabled somewhere and nobody knows. Retention is set in bytes on one topic and hours on another, and disk fills on a Friday. Consumer group lag is graphed but not alerted on. Each of these is a configuration decision, not an accident — which means each is preventable by someone who has been taught the model.
There is also a migration in progress. ZooKeeper-based clusters are being moved to KRaft, and that is a genuine operational project rather than a version bump. Teams need engineers who can plan and execute it, who can run a rolling upgrade without breaking replication, and who can size, secure and monitor a cluster properly — which is exactly the skill set that streaming, platform and SRE roles now hire for.
The model everything else follows from. Topics, partitions and offsets; why an append-only log served from page cache is fast; brokers, leaders and followers; and the target architecture for a real deployment — broker count, availability zones, storage choice and the cost profile that comes with it.
Topics: Topics, partitions, offsets and the append-only log · Sequential writes, page cache and zero-copy reads · Brokers, partition leaders and follower replicas · Producers, consumers and consumer groups at a high level · Target architecture across availability zones · Storage choices and the cost of a cluster · Where Kafka is the wrong answer
How the cluster agrees on who is in charge. What ZooKeeper does for Kafka, quorum sizing, configuration and the four-letter-word diagnostics; then KRaft, the controller quorum inside Kafka itself, and the migration path that most existing estates are somewhere along.
Topics: ZooKeeper's role in a Kafka cluster · Quorum sizing and ensemble configuration · ZooKeeper CLI, internal state and diagnostics · Factors that affect ZooKeeper performance · KRaft: the controller quorum and metadata log · Planning a ZooKeeper to KRaft migration · Controller failover and metadata recovery
From package to production broker. Installation and service setup, the broker configuration that matters, log directories and multi-disk layout, and the listener and advertised.listeners model — the single most common reason a client that works from the broker host fails from anywhere else.
Topics: Broker installation and service setup · Single broker, then a multi-broker cluster · Essential broker configuration parameters · log.dirs, multiple disks and JBOD considerations · listeners and advertised.listeners across networks · Running Kafka CLI commands for verification · Changing broker configuration statically and dynamically
The module that decides whether the cluster loses data. Replication mechanics and the in-sync replica set, how acks interacts with min.insync.replicas, unclean leader election and the availability-versus-durability choice it encodes, idempotent producers, transactions, and exactly-once semantics with its real limits.
Topics: Replication factor, leaders, followers and the ISR · acks settings and producer acknowledgement · min.insync.replicas and the combined guarantee · Unclean leader election and data loss · Idempotent producers and transactions · Exactly-once semantics and what it does not cover · Demonstrating cluster resiliency by breaking it
You may never write the client, but you will be asked why it is slow. Producer batching, compression and buffering; partitioning strategy and key skew; consumer groups, partition assignment and rebalancing; offset commit behaviour; and consumer lag as the health signal the whole cluster is judged against.
Topics: Producer batching, linger, compression and buffer memory · Partitioning strategy and key-based skew · Consumer groups and partition assignment strategies · Rebalancing, static membership and its cost · Offset commit behaviour and reprocessing · Measuring and alerting on consumer group lag · Diagnosing a consumer that is falling behind
Running the cluster after day one. Topic creation and the decisions that are hard to reverse, retention by time and size, log compaction and its use for changelog topics, partition reassignment and leader rebalancing, adding and replacing brokers, and rolling restarts that keep the cluster available.
Topics: Topic creation, partition count and what cannot be changed later · Retention by time and size, and segment behaviour · Log compaction and compacted topic semantics · Partition reassignment and throttled data movement · Preferred leader election and rebalancing · Adding, removing and replacing brokers · Rolling restarts and rolling upgrades
Where Kafka performance actually comes from, taken one resource at a time. Disk layout and filesystem choices, the page cache and why heap size is not the answer, network throughput and replication traffic, compression and CPU cost, and the operating system settings — file descriptors, virtual memory, network buffers — that quietly cap a cluster.
Topics: Kafka performance: disk I/O and filesystem choice · Kafka performance: network and replication traffic · Kafka performance: RAM, page cache and JVM heap · Kafka performance: CPU and compression cost · Kafka performance: OS settings, file descriptors and virtual memory · Benchmarking producers and consumers honestly · Running Kafka in production on cloud instances
Making a cluster fit to carry regulated data. TLS for client and inter-broker traffic, SASL mechanisms including SCRAM, PLAIN, GSSAPI and OAUTHBEARER, principal mapping, ACL authorization for topics and groups, client quotas to stop one team starving another, and the sequence for enabling all of this without an outage.
Topics: TLS for client and inter-broker connections · SASL mechanisms: SCRAM, PLAIN, Kerberos and OAuth · Principals, principal mapping and authorization · ACLs for topics, groups and cluster operations · Client quotas for produce, fetch and request rate · Enabling security on a running cluster incrementally · Auditing access and reviewing exposure
Knowing the cluster is unhealthy before consumers do. JMX metrics that matter, under-replicated and offline partitions, request latency percentiles, lag monitoring, log analysis, management tooling, then cross-cluster replication with MirrorMaker 2 and a recovery plan for the loss of a zone or a region.
Topics: JMX metrics and the signals worth alerting on · Under-replicated, offline and unavailable partitions · Request latency percentiles and broker saturation · Management tooling and cluster UIs · Log analysis and common broker failures · Cross-cluster replication with MirrorMaker 2 · Disaster recovery design and offset translation · Backup and restore of cluster metadata
The components that turn a cluster into a platform, and the operational load each adds. Kafka Connect in distributed mode with its own failure surface, Schema Registry and compatibility rules that prevent breaking changes, the REST proxy, Kafka Streams and ksqlDB from the operator's perspective, plus Kafka on Kubernetes and on managed services.
Topics: Kafka Connect in distributed mode: workers, connectors and tasks · Connect failure modes, dead letter queues and offsets · Schema Registry and compatibility enforcement · REST proxy and non-JVM clients · Kafka Streams and ksqlDB from the operator's side · Kafka on Kubernetes with the Strimzi operator · Managed Kafka: MSK and Confluent Cloud, and what stays yours
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a multi-broker cluster from scratch and fix the advertised.listeners problem that stops clients connecting from anywhere but the broker host.
Write continuously while killing partition leaders under three combinations of acks, replication factor and min.insync.replicas, and record exactly how many records disappeared each time.
Replace a broker in a live cluster using throttled partition reassignment, tracking under-replicated partitions and client impact throughout.
Enable inter-broker TLS and SASL/SCRAM incrementally on a cluster carrying traffic, then apply an ACL model for three tenant teams.
Benchmark a cluster to saturation, identify whether disk, network, CPU or an OS limit is the constraint, fix it, and re-measure to prove the gain.
Replicate topics with MirrorMaker 2, simulate the loss of the primary cluster, and move consumers across with offset translation and documented data-loss exposure.
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.