Junior · MongoDB with Go
One MongoDB client, many operations
Do you create and disconnect a MongoDB client for every HTTP request?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Reuse a concurrency-safe client across the application lifetime. It manages topology and connection pools; database and collection handles are lightweight views rather than independent servers.
Construction/configuration is not a readiness guarantee. Use a bounded readiness operation when needed, and give each query/write an operation context. Distinguish server selection, pool checkout and server execution when diagnosing latency.
Close the client after its users have drained. Size pool and admission budgets across replicas, protect credentials and verify the driver major version: v2 uses the /v2 import path and different APIs from old examples.
Common trap
A client per request repeatedly creates pools and monitoring work; a huge pool does not create database capacity.
Try it
A shared client starts successfully, but no database server is reachable. Can the first query fail?
Worked solution
Yes. Successful construction alone does not promise a usable server. A bounded Ping can test current connectivity but cannot guarantee later operations. Handle each operation error and keep readiness semantics distinct from liveness.
Change the constraint
How do you distinguish checkout wait from a slow query in telemetry?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.