Private corporate batches, live online cohorts and 1-on-1 mentoring in MongoDB operations — replica sets, sharding, backup and restore, indexing and cluster tuning — 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 MongoDB as cluster operations: replica set elections, member priority and hidden or delayed members; shard key selection and what a bad one costs once data is already distributed; read and write concern as a correctness decision rather than a tuning knob; and WiredTiger cache behaviour against a real working set. Every concept is demonstrated on a running cluster — an election forced by hand, a shard rebalance watched live, a profiler session used to find the query that is actually hurting, and a restore performed rather than described.
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 MongoDB that means a trainer who has run it in production — MongoDB operations — replica sets, sharding, backup and restore, indexing and cluster tuning — 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 MongoDB batchMongoDB is an open-source document database that stores records as BSON documents inside collections rather than as rows in fixed tables. There is no schema enforced by default — although schema validation is available and, in a production estate, usually advisable — so the shape of the data is decided by the application and the indexes are decided by the operator.
Operationally, MongoDB is a distributed system before it is a database. The standard production unit is a replica set: an odd number of members holding the same data, electing a primary through a Raft-derived protocol, with secondaries applying the oplog. Failover is automatic, which means the interesting questions are about election configuration, member priority, hidden and delayed members, and the read and write concerns that determine what a client is actually guaranteed. Beyond one replica set sits sharding — config servers, mongos routers, and a shard key choice that is close to irreversible and determines whether the cluster distributes evenly or hot-spots on a single shard.
The storage engine, WiredTiger, brings its own operational surface: document-level concurrency, a compressed on-disk format, and a cache whose sizing relative to the working set explains most MongoDB performance behaviour. Add the profiler, index management, oplog-based backup and restore, and role-based access control, and you have the real job — which persists whether the cluster runs on your own hosts, on Kubernetes through the operator, or on Atlas.
MongoDB has been in production long enough that the interesting problems are no longer about getting started. They are about clusters that were sized for a prototype and are now carrying real traffic, shard keys chosen before anyone understood the query pattern, replica sets running without authentication because that is how the tutorial had it, and backups that consist of a mongodump cron job nobody has restored.
The operational model is genuinely different from a relational database, and that difference is where teams get hurt. A replica set will fail over on its own, so the failure surfaces as inconsistent application behaviour rather than an outage — which makes read and write concern a correctness topic, not a tuning topic. Sharding rebalances in the background, so a bad shard key shows up as a slow, expensive migration rather than an error. WiredTiger cache pressure looks like random latency. None of this is guessable; it has to be taught.
Demand follows the estate. Platform and SRE teams are now expected to run MongoDB alongside everything else stateful, and the roles that ask for it want cluster operations — replica set and sharding design, security, backup and recovery, index and profiler work, and monitoring — rather than the CRUD API. Atlas has not changed that: it automates the machines, not the shard key, the index set, or the restore you have never rehearsed.
What you are actually running. BSON documents and collections, the mongod process, the WiredTiger storage engine and its cache, and the design decisions in a document model that later become operational problems — unbounded array growth, oversized documents, and collections that should have been separate.
Topics: BSON documents, collections and databases · The mongod process and its data files · WiredTiger: document-level concurrency, compression and cache · Schema validation and why schemaless still needs rules · Document model decisions with operational consequences · The mongo shell and mongosh as operational tools
Getting from a package install to something you would put traffic on. Configuration file structure, cache sizing against the working set, filesystem and mount options, ulimits and kernel settings, and deployment on cloud instances, containers and the Kubernetes operator.
Topics: Installation and the configuration file · WiredTiger cache sizing against the working set · Filesystem, mount options, ulimits and kernel tuning · Journaling, durability and checkpoint behaviour · Deploying on cloud instances and in containers · The MongoDB Kubernetes operator · Managed MongoDB and what it does not remove
The module that fixes the most common real-world MongoDB defect. Enabling authentication properly, the built-in and custom role model, per-database privilege design, TLS for client and intra-cluster traffic, keyfile and x.509 internal authentication, and network exposure that does not put a cluster on the public internet.
Topics: Enabling authentication on an existing cluster without an outage · Built-in roles and designing custom roles · User management across databases and authentication databases · TLS for client and intra-cluster connections · Keyfile and x.509 internal authentication · Network binding, firewalling and exposure review · Auditing and the operations log
The production unit of MongoDB. Building a replica set, how elections work and what triggers them, member configuration — priority, votes, hidden, delayed and arbiter members — the oplog and its sizing, replication lag, and rolling maintenance that keeps the set available throughout.
Topics: Setting up replica set members and initiating the set · Elections, majorities and what triggers a stepdown · Member configuration: priority, votes and tags · Hidden, delayed and arbiter members and when each is right · The oplog: sizing, window and replication lag · Rolling maintenance and rolling upgrades · Testing failover deliberately
The topic that decides whether an application is correct on a distributed database. Write concern levels and their latency cost, read concern including majority and linearizable, read preference and the staleness it introduces, causal consistency and sessions, and retryable reads and writes during failover.
Topics: Write concern: w, j and wtimeout · Read concern levels and majority read behaviour · Read preference and reading from secondaries · Staleness, causal consistency and client sessions · Retryable reads and writes during elections · Transactions across documents and shards, and their cost
Scaling horizontally, and the decision that is hardest to undo. Sharded cluster components, config servers and mongos routers, shard key selection — hashed, ranged and compound — chunk splitting and migration, the balancer, zone sharding for locality, and what actually happens when a shard key turns out to be wrong.
Topics: Sharded cluster components and the sharding workflow · Setting up config servers and mongos routers · Adding shards and sharding a collection · Shard key selection: ranged, hashed and compound · Chunks, splitting, migration and the balancer · Zone sharding for data locality · Diagnosing hot shards and jumbo chunks · Resharding and the cost of getting it wrong
Recovery you have actually performed. Logical backup with mongodump and mongorestore and its limits at scale, filesystem and cloud snapshots on a consistent set, oplog-based point-in-time recovery, backing up a sharded cluster consistently, and turning the whole thing into measured RPO and RTO numbers.
Topics: mongodump and mongorestore: mechanics and limits · Filesystem and volume snapshots on replica set members · Oplog capture and point-in-time recovery · Backing up a sharded cluster consistently · Restoring a single collection versus a whole cluster · Restore rehearsal, RPO and RTO as measured numbers · Recovering from a logical error using a delayed member
Finding the real problem and proving the fix. Index types and compound index ordering, explain output read properly, the database profiler and slow operation log, aggregation pipeline cost and index usage, monitoring signals worth alerting on, and version upgrade paths across replica sets and sharded clusters.
Topics: Index types: compound, multikey, text, partial and TTL · Reading explain output and index bounds · The database profiler and slow query analysis · Aggregation pipeline stages and their cost · currentOp, killOp and live incident handling · Monitoring: serverStatus, exporters, Prometheus and Grafana · Capacity planning against the working set · Upgrade paths for replica sets and sharded clusters
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a three-member replica set, manipulate priority and votes, force a stepdown, and account for exactly which member was elected and why.
Take an unauthenticated replica set, enable keyfile internal auth and role-based access control through a rolling restart, and prove no client connection was dropped.
Shard a collection on a monotonically increasing key, watch the hot shard develop, then reshard onto a better key and measure the migration cost.
Capture oplog, run a destructive bulk update, then restore the cluster to the instant before it and verify the data with a checksum comparison.
Enable the profiler on a loaded cluster, identify the operations dominating the workload, and fix each with an index or aggregation change measured by explain.
Run a monitored sharded cluster through a member loss, a rolling upgrade, a balancer incident and a restore drill, documenting each intervention and its 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
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.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| 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.