Challenge 3: Fix a Connection-Per-Request Anti-Pattern — Possible Solution ==================================================================== WHAT'S WRONG ------------------------------ Creating a new MongoClient and calling .connect() inside every single request handler means every incoming request pays the full cost of establishing a brand-new connection (and spinning up its own internal connection pool) from scratch, rather than reusing a connection that's already established. Under real traffic — many requests arriving close together — this can quickly exhaust the number of connections MongoDB's server allows at once, causing later requests to fail or queue up waiting for a connection slot, purely because of how the application is managing (or failing to manage) its connections, not because of anything wrong with the actual queries themselves. THE FIX ------------------------------ Create the MongoClient ONCE, outside of any individual request handler — typically when the application starts up — and reuse that same client instance for every request that comes in afterward: // At application startup, NOT inside a route handler: const client = new MongoClient("mongodb://localhost:27017"); await client.connect(); const db = client.db("shop"); // Inside each route handler, reuse the already-connected client: app.get("/products", async (req, res) => { const products = await db.collection("products").find({}).toArray(); res.json(products); }); WHY THIS WORKS AS AN ANSWER ------------------------------ A MongoClient's internal connection pool is specifically DESIGNED to be created once and shared across many operations over the application's entire lifetime — that's the whole point of a "connection pool" existing at all. Reconnecting per request throws that design away and pays the full connection-setup cost on every single request instead of just once at startup, which is exactly the same underlying mistake node2-5's MySQL connection-pooling material warned against, just applied to MongoDB's driver instead.