Why should you care?

When Swiggy or a SaaS hits traffic spikes, one lonely mongod is a single point of failure. Architecture choices (replica set vs shard) decide uptime and scale.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

// Check what you are connected to
db.hello()
db.serverStatus().host
db.serverStatus().version
// Local single node often reports as standalone or a 1-member set

Run Example »

This lesson uses terminal or setup steps. Run commands on your computer — the live editor appears on coding lessons.

What happened?

• db.hello() shows topology info (standalone, replica set primary, etc.).
• serverStatus exposes host and version.
• On your laptop you usually run one mongod; in production you add replicas and maybe shards.

Practice next

1. Connect with mongosh and run db.hello().
2. Note whether ok is 1 and what msg/topology says.
3. Run db.serverStatus().version and write it down.
4. Run db.adminCommand({ listDatabases: 1 }) and list names.
5. Compare db.hello() output before and after starting a local replica set (later lesson).

Remember

mongod stores and serves data. Clients talk over the MongoDB wire protocol. Replica sets and sharding are production architecture layers.

Banking API needs always-on reads

A payments team runs three mongod nodes as a replica set so one machine dying does not take the app offline.

Outcome: Clients keep reading and writing through automatic failover.