03 / 15

What are the components of a sharded cluster?

Difficulty: 5/10
config servers, shards, mongos routers

A MongoDB sharded cluster consists of the following components:

  1. 1

    shard: Each shard contains a subset of the sharded data. Each shard must be deployed as a replica set.

  2. 2

    mongos: The mongos acts as a query router, providing an interface between client applications and the sharded cluster.

  3. 3

    config servers: Config servers store metadata and configuration settings for the cluster. Config servers must be deployed as a replica set (CSRS).

Scenario Questions

0-2 years experience

  1. 1If you need to set up a small MongoDB sharded cluster for a new microservice, which components would you provision and how do they interact?
  2. 2What would happen if you start a mongos instance without any config servers configured?
  3. 3How does a client query get routed through the sharded cluster components?

2-5 years experience

  1. 1We noticed that writes to a particular shard are failing with a 'stale config' error. Which component is responsible for detecting and fixing this, and how would you troubleshoot it?
  2. 2During a rollout, the balancer stopped moving chunks and the cluster became imbalanced. Which parts of the sharded architecture would you examine first and why?
  3. 3Explain the trade‑offs of placing config servers in a replica set versus a single node when scaling a sharded cluster.

5-8 years experience

  1. 1Design a sharded cluster that can handle 10,000 writes per second with high availability across three data centers. Which components would you configure, and how would you ensure minimal cross‑datacenter latency?
  2. 2A hot shard is causing performance bottlenecks. Describe how you would use the sharding components to redistribute load without downtime.
  3. 3Discuss the impact of adding a new shard on the config server workload and the balancer, and how you would mitigate any risks.

8+ years experience

  1. 1Our organization plans to migrate from a monolithic replica set to a sharded architecture over several years. Outline the high‑level steps and how you would evolve the config server and mongos layers to support a phased migration.
  2. 2When multiple teams share a sharded cluster, how would you structure the config server and mongos deployment to enforce isolation and governance while keeping operational overhead low?
  3. 3Predict how future changes in MongoDB's sharding metadata format could affect existing config server deployments, and propose a strategy to future‑proof the architecture.

Follow-up Questions

  • What monitoring would you put in place for those components?
  • How would you handle a config server failure?
  • What are the implications of scaling the number of mongos routers?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.