Q24 of 37 · Selenium

Explain the Selenium Grid architecture (hub/node) and when to use it.

SeleniumMidseleniumgridarchitectureparallel

Short answer

Short answer: Grid distributes WebDriver tests across machines. A hub receives session requests and routes to a pool of nodes that host browsers. Use it for cross-browser/cross-OS coverage or to scale parallel runs beyond a single host.

Detail

Components in Grid 4:

  • Router — public entry point; receives new RemoteWebDriver(...) requests.
  • Distributor — picks a node that satisfies the requested capabilities (browser, version, platform).
  • Session Map — tracks which node is running which session.
  • Event Bus — coordinates messages between components (often Redis-backed in production).
  • Node — runs the actual browser. Each node registers its capabilities (e.g. "Chrome 120 on Linux, 4 sessions max").

In a "standalone" deployment, all of these run as one process on one box. In a distributed deployment, each runs separately, and you scale by adding nodes.

When to use Grid:

  1. Cross-browser coverage you can't get on one box. A Mac node for Safari, a Windows node for Edge, Linux nodes for Chrome/Firefox.
  2. Parallel scale beyond one machine. Once your suite needs ~16+ concurrent browsers, a single host can't keep up — disk and RAM contention destroy reliability.
  3. Mobile coverage via Appium-on-Grid or device farms registered as nodes.

When you don't need Grid:

  1. Small / medium suites running on one CI runner. A single CI machine running 4-6 parallel Chrome instances is cheaper and simpler.
  2. Single-browser testing. If you only target Chrome on Linux, parallel docker-compose with one image scales fine.

Common patterns:

  • Docker compose for local: a hub container plus chrome/firefox node containers.
  • Kubernetes for production scale: one of the Grid-on-K8s charts spins nodes elastically.
  • Cloud alternatives (Sauce, BrowserStack, LambdaTest) are managed Grid-equivalents — usually worth it before standing up your own infrastructure.

The interview signal: knowing the components, articulating the cross-browser / scale-out reasons, and being honest about when Grid is overkill.

// WHAT INTERVIEWERS LOOK FOR

Hub/node mental model with the Grid 4 components, two clear use cases (cross-browser, parallel scale), and the honesty to say Grid is unnecessary for most small projects.

// COMMON PITFALL

Recommending Grid as a default for any Selenium project. For small suites, a single Docker host with 4 parallel Chromes is simpler, cheaper, and just as reliable.