Explain Selenium Grid 4 architecture

Selenium Grid lets RemoteWebDriver sessions run on remote machines so you can scale and cover browser/OS combinations. Grid 4 was rewritten from scratch: the old monolithic hub was split into components that can run in one process or be deployed separately.

The components

Router

The single entry point (by default on port 4444). Every request from a client goes to the Router. A new session request is sent to the Session Queue. Any request for an existing session (/session/{id}/...) is looked up in the Session Map and forwarded directly to the Node that owns it.

New Session Queue

Holds new-session requests in FIFO order until a slot is free. Requests that wait longer than the configured timeout (--session-request-timeout) are rejected, which is what you see when a suite starts more threads than the Grid has capacity for.

Distributor

Keeps a model of all Nodes and their slots (a slot is one browser of a given type that can run a session). It pulls requests from the queue, matches the requested capabilities (browserName, browserVersion, platformName and custom se: capabilities) against free slots, and asks the chosen Node to create the session.

Session Map

A key-value store of session ID to Node URI. The Router consults it for every command after session creation. In distributed setups it can be backed by an external database.

Event Bus

The internal messaging backbone (ZeroMQ-based by default) that components use for events such as node registration, heartbeats and session closed. Nodes announce themselves over the bus.

Nodes

Machines that actually run browsers. A Node detects the browsers and drivers available (Selenium Manager can resolve drivers), exposes slots, and enforces --max-sessions. A Docker Node variant starts a fresh container per session from configured images, which gives clean, isolated browsers.

Request flow

Client --new session--> Router --> Session Queue
                                      |
                              Distributor (match capabilities to a free slot)
                                      |
                                    Node creates session --> Session Map stores id->node
Client --/session/{id}/element--> Router --(lookup Session Map)--> Node --> driver --> browser

Deployment modes

# Everything in one process: quick local or CI setup
java -jar selenium-server-<version>.jar standalone

# Classic topology: hub = router + distributor + session map + queue + event bus
java -jar selenium-server-<version>.jar hub
java -jar selenium-server-<version>.jar node --hub http://hub-host:4444 --max-sessions 4

# Fully distributed: each component started separately (event-bus, sessions,
# sessionqueue, distributor, router, node) for large or highly available setups

In practice most teams use the official selenium/standalone-*, selenium/hub and selenium/node-* Docker images, or the docker-selenium Helm chart on Kubernetes, which can autoscale Nodes from queue length using KEDA.

Observability

Grid 4 exposes a web UI and a GraphQL endpoint (/graphql) for querying nodes, slots and queue size, and supports OpenTelemetry tracing. Queue length is the key capacity signal: a growing queue means you need more Nodes or fewer concurrent tests.

Design considerations

• Capacity: concurrency in the test runner must not exceed free slots, or sessions queue and time out.
• Isolation: one session per container avoids state leaking between tests.
• Resources: browsers are memory-hungry; oversubscribing a Node causes slow, flaky sessions.
• Network: every WebDriver command is a round trip through the Router, so keep the Grid close to the CI agents.

What interviewers look for

• Correct roles for Router, Distributor, Session Map, Session Queue, Event Bus and Node.
• The difference between new-session routing and existing-session routing.
• Practical knowledge of deployment modes, Docker/Kubernetes and capacity planning.

Follow-up questions

• How would you autoscale Nodes based on demand?
• What happens to running sessions if the Distributor restarts?